Inhaltsverzeichnis von SUSE Linux

- Weitere Informationen zu diesem Buch:
  Inhaltsverzeichnis |

JETZT ONLINE BESTELLEN

SUSE Linux

By Chris Brown & PhD

First Edition August 2006
ISBN 978-0-596-10183-1

446 Seiten

EUR32.00, SFR54.90

Weitere Informationen zu diesem Buch

Inhaltsverzeichnis |

Inhaltsverzeichnis

Chapter 1: Quick Start

Inhaltsvorschau

I have never liked delayed gratification. I don't buy self-assembly furniture or bake cakes from scratch—there's too much waiting involved. Bonsai? You must be joking! With software products and operating systems especially, I want to start putting them to use the instant I have them in hand. Hopefully, this book will help you do that with SUSE Linux. In particular, this first chapter is intended to get you started quickly—to get the system installed; to get your printer, email, and network set up; and to take a step on the road to self-sufficiency through reading the documentation. Changing your operating system is like moving to a new home. You need to figure out how to turn on the electricity, water, and heating. You need to make a hot drink. You need to get the bed assembled before nightfall. Unpacking your CD collection can wait.

Once the system is installed, I suggest you spend some time exploring the menus. From web browsers to HTML editors, from databases to CD players, from image editors to chess programs—there's just so much stuff! And that's just the graphical tools. A whole new world of command-line utilities also awaits you. As the SUSE folks say, "Have a lot of fun."

Not too long ago—five years, maybe—installing Linux required a great deal of patience and technical know-how. Getting it to work properly on a laptop was especially tricky, rather like teaching chickens to fly. Anyone found in possession of a flying chicken would be besieged by questions from others anxious to see their pet hen airborne. Since then, the device support in Linux has improved beyond recognition; the installation tools in a modern Linux distribution auto-detect most hardware, install the right drivers, and deliver a default installation that is almost certainly going to work.

In this lab I walk through a typical installation of SUSE Linux from local media (in this case, a DVD or set of CDs). Everyone's installation is different, of course. You may be installing onto a completely "empty" machine, or you may wish to preserve existing partitions and operating systems. You may have specific requirements for the selection of software you want to install. You almost certainly have different hardware than I do. For this walk-through, I use a desktop machine of dubious breeding (I built it myself), which has an existing installation of Windows 2000 (which I will keep) and an existing installation of an earlier version of Linux (that I will replace). Depending on which version of SUSE Linux you're installing, there may be some minor differences between the screens you'll see and the screenshots in this book.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Installing SUSE Linux from Local Media

Inhaltsvorschau

Start by booting from the DVD included with your SUSE Linux distribution. (If your machine won't boot from DVD, or if you've created the CDs by downloading ISO images from the OpenSUSE web site [http://www.opensuse.org], boot from CD1.) You will be presented with an initial boot menu that will (if you let it time out) boot from the hard drive. This isn't what you want, so select "Installation" from the menu. A Linux kernel and a RAM-disk image will now be loaded from the DVD or CD. The RAM-disk image is a small filesystem, held in memory, that Linux uses during the installation. You'll be asked to select the language you want to use for the installation.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Set Up a Local Printer

Inhaltsvorschau

Moving to a new computer, or to a new operating system, is a bit like moving into a new house. It takes a while to feel comfortable in it, and to get all your stuff arranged just how you want it. And if you're moving, one of the first things you'll want to do in your new home is make a cup of tea. So, it's particularly important to clearly label the packing case in which you packed the tea bags and the kettle. Similarly, if you're migrating to a new desktop operating system, one of the first things you'll want to get working is your printer.

If you're living in a country, such as the United States, where it is almost impossible to buy anything that the British would regard as even remotely resembling tea, feel free to think of coffee and coffeepots.

In this lab you'll see how to set up a locally connected printer. In Chapter 2 you'll see how to connect to a print server across the network.

You will configure the printer using YaST (Yet another Setup Tool). YaST is an integrated collection of modules that perform a wide variety of system administration tasks from a graphical user interface. It is a key component of SUSE Linux and you will meet it many times in this book.

If your printer was plugged in when you installed SUSE Linux, you'll probably have been offered the opportunity to configure it at that stage. If not, it is easy to add a locally connected printer. In fact, if you simply plug in a printer to a USB port, SUSE should automatically detect it and display a New Hardware Found dialog box asking whether you want to configure it. Answering Yes in this dialog box will start the YaST printer module. As always, when YaST starts up, it will display the Run as Root screen to ask you for the root password. YaST should auto-detect the printer and include it in the list of available printers in the main printer configuration screen, as shown in Figure 1-9.

Figure 1-9: YaST main printer configuration screen

Select the printer from the available printers list and click Edit. This will take you to the Edit Configuration screen shown in Figure 1-10.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Get Started with Email

Inhaltsvorschau

After getting your printer set up, one of the next things you will want to get working on Linux is email. Assuming that you have Internet connectivity (either broadband or dial-up), this process is quite straightforward. There are many mail user agents for Linux. (Mail user agents are the programs that let you read, compose, and organize your mail.)

Both KDE and Gnome desktops include graphical mail user agents; for KDE there's KMail and for Gnome there's Evolution. Mozilla Thunderbird is also available, but is not installed by default. If you're coming from a Windows background, think of these as roughly equivalent to Outlook Express.

Section 1.3.1.1: Kmail

Start Kmail from the KDE desktop using Main Menu → Internet → KMail. (Later, you may want to add a launch icon for KMail onto the toolbar. You'll see how to do that in Chapter 3.) The very first time you launch Kmail, it will offer a wizard that guides you through a few screens to set up an initial account. I recommend that you cancel the wizard on its first screen, and proceed to the main KMail screen, from which you can set up your own accounts.

Before you can send and receive email with Kmail you will need, at minimum, to define an "identity" and specify your ISP's inbound and outbound mail servers.

Incoming mail is usually received from a POP3 or IMAP server. Outbound mail is usually sent to an SMTP server. The mail servers for incoming and outgoing mail are entirely separate and may not even be operated by the same service provider. In any case, they need to be configured separately in KMail.

From KMail's main menu, select Settings → Configure KMail. The configuration dialog has several sections that you can select via the pane on the left. Begin by selecting Identities. An identity is basically just a named collection of KMail configuration settings. You probably won't need to define more than one of these, so click Modify to edit the default identity. Complete the form by entering your name, organization and email address (as you would like them to appear on outbound mail) and click OK.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure a Network Card

Inhaltsvorschau

It's perfectly possible to install and operate a completely standalone Linux system with no network connection at all, but it's rather unusual. Most systems need to connect to a local area network, either in the office or at home. In this lab you'll see how to configure a network card to connect to a local wired network (i.e., Ethernet). I'll begin by looking at the traditional YaST way (which requires the root password), then I'll look at a couple of more recent applets (netapplet and NetworkManager) that allow easy—though limited—management of network interfaces without root privilege. In Chapter 6, you'll see how to set up wireless networking.

If your network card was auto detected during installation, you will have been offered the opportunity to configure it at that stage. If not, or if you need to configure it later, use YaST (K Menu → System → YaST).

On YaST's main screen, select Network Devices from the panel on the left, then Network Card from the panel on the right. On the main network card configuration screen, you will see a list of available (but unconfigured) cards. To configure one of these, select it from the list and click Configure.

A list of already-configured devices is shown at the bottom of the screen. To change one of these, click Change. On the next screen, titled Network Card Configuration Overview, you'll again see the list of configured cards. They will probably have names like "eth-id-00:01:02:8E:21:9." Select the card that you want to configure and click Edit. This will bring you to the Network Address Setup screen shown in Figure 1-15.

Figure 1-15: Assigning an IP address

The easiest way to configure a network card is to select Automatic Address Setup (via DHCP). Using this method, the machine will broadcast a request over the network when it starts up (or to be more accurate, whenever the interface is activated), hoping to find a DHCP server that will supply its IP address, subnet mask, default gateway, and other network settings. This choice is usually appropriate if you are putting your machine onto a corporate network, which probably operates a DHCP server. If you have a home network with an ADSL modem/router, it's likely that the router offers DHCP, so you can use this setting here also.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Access Documentation

Inhaltsvorschau

It used to be said that Unix and Linux were short on documentation. Nowadays, if anything, there's too much. This lab will guide you to some of the sources of documentation.

I will deal first with the most traditional source of documentation for Unix and Linux systems, the so-called "manual" pages, often abbreviated to "manpages." The usage and format of these goes back many years. They were originally intended to document the command-line tools, and that is still their main purpose. You will, generally speaking, not find manpages for the graphical tools.

From a command prompt, access the manpages with the man command; for example:


chris@snowhite:~> man gcc

will show the manual page for the GNU C compiler (the first screen of it is shown in Figure 1-19).

Figure 1-19: The manual page for gcc

As you'll see even from this small example, the manpages are very terse. The content is provided under various standard headings—NAME, SYNOPSIS, DESCRIPTION, OPTIONS, and so on. Most of them have a SEE ALSO section near the end, which provides a cross-reference to related commands. The manpages vary enormously in length and complexity. The page for the id command is just 64 lines. The page for gcc is over 9,000 lines. When viewed from a command prompt, manpages are piped through the program less to allow you to browse them. I discuss less in more detail in Chapter 2, but for now it is sufficient to know that you can press the up and down arrow keys to scroll through the material, and q to quit.

Of course, looking up a command by name works only if you already know the name of the command. If you don't, you can try using the apropos command to search the keyword-in-context index of the manpages and show matching entries. For example:


chris@snowhite:~> apropos compiler

will show you all manpages with the word 'compiler' in their 'NAME' section.

There are other ways to access the manpages. From the Konqueror browser, for example, entering "man:gcc" into the location field will show you the manpage for gcc. It is formatted to look a little prettier than viewing it from the command prompt, but it's derived from exactly the same unformatted source, so the actual content is identical.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 2: Basic System Administration

Inhaltsvorschau

Once upon a time, Unix (the forerunner of Linux) had no graphical desktop at all. A command prompt was the only user interface. Of course, Linux now has a high-quality, modern, graphical desktop (indeed, it has more than one). Nowadays there are tools that let you perform most system administration through a graphical interface (in particular YaST, in SUSE Linux). Nonetheless, Linux retains its command-line interface (you'll also hear this referred to as a shell prompt, "shell" being the Linux name for a command interpreter), and you'll find plenty of Linux users (especially the hardcore geeks) who prefer this interface to the graphical tools. Throughout this book, I'll often discuss how to perform a particular task using graphical tools and how to do the same thing from the command line. It is not my intention to embark on a religious crusade in favor of either the graphical desktop or the command line. Both have their strengths and weaknesses. Which you prefer depends largely on your background and expectations.

It is easy to access a command prompt from a Linux desktop. In KDE, for example, select System → Terminal → Konsole from the main menu. There is also an icon on Kicker (the KDE main panel). Either method will bring up a terminal window and start a shell. For a really old-fashioned, authentic view of the command line, you can use the shortcut keys Ctrl-Alt-F1 through Ctrl-Alt-F6 to view up to six virtual terminals on which you can log in and enter commands. (From a virtual terminal, use Alt-F7 to return to the graphical desktop.) When comparing Linux to Windows, it's important to note that you don't have to install a window manager or any graphical applications if you don't want to. Indeed, Linux systems intended for use as, say, a mail server or a database server are usually set up this way.

When the shell is ready for another command, it prints a prompt. The prompt can be configured to be anything you want, but by default it is of the form:


username@hostname:directory>

For example:


chris@snowhite:~>

Note that the tilde (~) is a shorthand notation meaning "my home directory." For simplicity, in this book I show the prompt simply as

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

View and Edit Text Files

Inhaltsvorschau

Linux uses a lot of files that contain "plain old text," including (almost without exception) all system-wide and user-specific configuration files. Being able to view and edit such files is a key skill for driving Linux in anything beyond first gear. This lab looks at some of the tools for viewing and editing plain text files, and covers both graphical tools and command-line tools.

If you're using a graphical desktop, clicking on a text file in either the Konqueror file browser (KDE) or in Nautilus (GNOME) displays the contents of a text file in the browser's window.

From the command line, a good tool for viewing a text file is less. It's easy to run: you just supply the filename as an argument:


$ less /usr/share/doc/packages/sodipodi/README

The name less is a reference to an earlier and simpler program called more, which let you browse through the file a screenful at a time. Each time you pressed the spacebar, you saw more of the file. The later program less is actually fancier; in particular, you can page up as well as down through the file. "Less is more" is the wisdom on the streets. You will discover that the names of many Linux commands are either (a) an historical accident, (b) an obscure reference to something that came earlier, or (c) a testimony to the somewhat limited sense of humor of people who give names to Linux commands.

When you run less, it will display the first screenful of the file, then pause, wondering what to do next. There are many single-character commands that you can enter at this stage; typing h will show you a command summary (the top part of which is shown in Figure 2-1), but you can drive less satisfactorily with rather few commands (see Table 2-1).

Figure 2-1: Part of the help screen for less

Table 2-1: Key commands for less
Command	Description
Spacebar or Page Down

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Explore the Filesystem

Inhaltsvorschau

Linux, like Windows, has a hierarchical filesystem. That is, there is an organization of folders and subfolders arranged in a tree. In the Linux world, you are more likely to hear folders referred to as directories; the two terms are interchangeable. If you're coming from a Windows background, there are a few differences you'll need to get accustomed to.

First, a typical pathname for a file in Windows looks like this:


C:\Program Files\Adobe\Acrobat 6.0

Here's an example of a pathname in Linux:


/opt/mozilla/bin

First, notice that Linux uses forward slashes ("/") to separate the components of a path name, not backslashes ("\"). This is easy to get used to. Second, Linux does not use drive letters like C: and D:. I know that users coming from a Windows background have grown very attached to their drive letters and sometimes view their absence in Linux as an omission. I would prefer that you see it as progress. Even though a filesystem on Linux may be split across several drives (including hard disk partitions, removable media such as CDs, and filesystems on remote file servers), everything is assembled together into a single filesystem tree. When you make reference to a file, you do not need to know which drive it is on, or whether it is local or remote—you just need to know its name. You'll see how this works later.

The most significant differences between the Windows and Linux filesystems, however, lie in the actual organization—the actual names of the directories and the details of what goes where. This lab describes that organization and also examines the tools that will allow you to explore the filesystem.

From the KDE desktop, use Konqueror to browse the filesystem. Konqueror is the Linux equivalent of Windows Explorer. To launch Konqueror, click on the blue "home" icon on the main panel. This will launch Konqueror in your home directory. Konqueror has several view modes, selectable from the View → View Mode menu. These include:

An icon view

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Manage Files and Directories

Inhaltsvorschau

There are some fundamental skills needed for any operating system—the ability to create, move, rename, and delete files and directories—that everyone needs. This lab shows how to do those things using both the graphical desktop and the command line.

The previous lab discussed the use of Konqueror and the command-line tools to browse the filesystem. Table 2-5 compares some graphical and command-line operations.

Table 2-5: Comparing graphical and command-line operations
To do this	In Konqueror	From a command prompt
Delete a file	Right-click the file and select Move to Trash from the context menu.	$ rm filename
Rename a file	Right-click the file and select Rename from the context menu. Enter the new name.	$ mv oldname newname
Copy a file	Control-click to select the file, then type Control-C or select Edit → Copy from the menu. Navigate to the destination directory, and then type Control-V or select Edit → Paste from the menu. You can also copy files using drag-and-drop between two Konqueror windows.	$ cp oldname newname
Create a file	Right-click a whitespace area and select Create New from the menu that appears.	$ touch filename

There is rather more power and subtlety in the command-line tools than the table suggests. For one thing, all of the commands can operate on multiple files. So, for example:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Set File Access Permissions and Ownership

Inhaltsvorschau

So far, I have conveniently ignored the issue of access permissions (i.e., who can do what) on files. Traditionally, a full discussion of the Linux security model is part of any introductory Linux course or text. But in fact, if you have a basic Linux setup with just a few user accounts on it, you can get by without knowing much about the security model at all because Linux will, for the most part, just do the right thing.

"The right thing" basically means this:

You will be able to view and modify any files that you yourself create.
You will be able to view (but not modify) the contents of files created by other users who have accounts on the system. (This may be a more permissive arrangement than you'd like.)
You will be able to view (but not modify) most system files.
If you're logged in as root, you can do anything!

This lab explores the underlying security model in Linux and shows how to change a file's ownership and access permissions, both from a graphical interface and from the command prompt.

To view or change a file's attributes using Konqueror, right-click the file and select Properties from the file menu. In the file properties dialog, the General tab shows the file's size and its timestamps. You cannot edit these. Click the Permissions tab to see and change a file's ownership and access permissions. This dialog provides drop-down lists to allow you to set the access rights on the file to be read/write, read-only, or forbidden (no access). You can set the permissions separately for the owner of the file, for members of the file's group, and for everyone else (Others).

These permission sets are actually a slight simplification of the real underlying permissions, which you can see if you click Advanced Permissions. Figure 2-7 shows the permissions dialog and the advanced permissions screen.

Figure 2-7: Showing file permissions in Konqueror

Ignoring, for the present, the Special permissions shown in Figure 2-7, you can see that each file carries read, write, and execute permission for its user (meaning the owner), members of the file's group, and everyone else. Read and write are hopefully self-explanatory. Execute permission allows the file to be executed as a command and is really only appropriate for fully compiled applications (what Windows would call an

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Access a Remote Printer

Inhaltsvorschau

I have a confession to make. I don't understand how printing works in Linux. Back in the days of the lpd printing daemon in Unix, I had a reasonable idea of what was going on. I could even get it to work. Nowadays, most Linux printing is done using CUPS (the Common Unix Print System). Although in some ways it's much easier to use (you just press the obvious buttons and—hey presto!—it works), the underlying architecture is something of a mystery. I put this lack of understanding down in part to my advancing years, but also in part to the lack of a really good description of the CUPS architecture. Also, it is difficult to disentangle the underlying CUPS system from the printer configuration tools that are supplied as part of the KDE desktop and as part of YaST.

Notwithstanding these problems, in this lab you'll learn how to set up your SUSE Linux system to print to a remote printer.

You can configure access to a remote printer using YaST. From the main YaST screen, select Hardware from the panel on the left, and then Printer from the panel on the right. This will bring you to the top-level Printer Configuration screen. From this screen, click on Add. The next screen asks if your printer is local ("Directly Connected") or remote ("Network Printers"). Select Network Printers at this point. This will bring you to the Printer Type screen shown in Figure 2-9. (In versions of SUSE Linux prior to 10.1, selection of local and remote printers was combined into a single screen.)

Figure 2-9: Defining the connection type for a remote printer

This screen is poorly named. It really refers to the type of the connection, rather than the type of the printer itself. As you will see from the figure, you can define queues to remote printers using a variety of protocols (CUPS, LPD, SMB, IPX, and network printers). In this lab, you need to select "Print via CUPS Network Server." On the next screen, labeled Connection Type, you have three choices:

CUPS client only: This selection is appropriate if your network has a single CUPS server that has multiple printer queues. All the named print queues on this server will be made available for use on your machine. "Client only" is a convenient and reliable way of working, and I would recommend it if your machine stays connected to a single network. Note, however, that it can cause problems if you take your machine off that network, as some applications (notably OpenOffice and Firefox) present very long start-up delays (several minutes) as they try to enumerate the printer queues on a nonexistent print server. I have even seen delays in restarting the YaST printer module if the print server is taken offline.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Create User Accounts

Inhaltsvorschau

Creating user accounts is one of the most fundamental tasks of system administration. Even in the simplest case of a machine intended for use by a single person, you should create a proper user account for yourself. In Windows installations, it's not uncommon to create just one user account that has administrative privileges and to use that for everything. Doing this on Linux is a really bad idea (actually, it's a bad idea on Windows, too) because if you're permanently logged in as root, there are no underlying safeguards to stop you from inadvertently deleting or overwriting vital files, or to prevent malicious scripts or programs that you run from doing bad things to your system.

For a machine intended for home use, you should create accounts for everyone who wants to use your machine: your roommate, your spouse, each of your kids, and so on. That way, everyone can maintain their own preferences and settings and have a piece of the filesystem (their home directory) to call their own. For a machine intended for use as a company-wide server, you may find yourself maintaining hundreds or thousands of user accounts.

As with most things, there are graphical and command-line tools for creating and managing user accounts. All these tools manipulate the same underlying files and account information.

Some people talk about "creating users" rather than "creating accounts," but to literal-minded folk like me, creating users is a biological activity well outside the scope of this book.

There's a YaST module for managing user accounts. From YaST's main screen, select Security and Users in the panel on the left, and then choose User Management from the panel on the right. This will bring you to the main user management screen shown in Figure 2-10.

Figure 2-10: The main user administration screen in YaST

Click on the Set Filter button and select Local Users. This will allow you to manage user accounts that are stored in local files. From this screen you can add new accounts or edit and delete existing accounts.

To add a new local account, click Add. This will bring you to the New Local User screen shown in Figure 2-11.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Rescue a System That Won't Boot

Inhaltsvorschau

You don't usually expect problems at boot time. You expect to simply switch on and be greeted by a login prompt soon after. So it can come as a bit of a shock if the boot process comes to a screaming halt. This lab examines some techniques for recovering systems that won't boot, and, as a side effect of this, how to recover if you forget the root password.

There is no "one size fits all" solution to the problem of fixing systems that won't boot, but I offer some general pieces of advice: first, you need some understanding of how the system is supposed to boot in the first place, and second, you need to read the boot-time messages very carefully and try to figure out how far the boot process actually got and what the first indication of trouble was (i.e., the first error message). I emphasize "first" here because the system may stagger on a ways and produce further messages or errors before actually stopping.

SUSE Linux normally covers up the boot-time messages with a pretty splash screen. To view the boot process in detail, press Escape (or F2 in some versions).

My third piece of general advice is even more obvious. Most boot-time failures occur as a result of making some configuration change, so it helps if you can remember what you changed! (And as a rule, when you're changing something tricky, make one change at a time, reboot to make sure all is well, and move on to the next change.)

Assuming that the boot process gets as far as loading the boot loader GRUB (GRand Unified Bootloader), it will, left to its own devices, time out and boot using whatever commands are defined as the default in its configuration file /boot/grub/menu.lst. You can interrupt the process by pressing Escape when you see GRUB's boot menu. This will drop you into a character-mode interface that will allow you to edit the GRUB commands that will be used to boot the system, or even to type new commands in from scratch. A common use of this technique is to append parameters to the settings used to boot the kernel. In particular, appending the word single to the kernel command in grub will make the kernel boot in single-user mode.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Finding Files

Inhaltsvorschau

It's not unusual to forget where you put a file that you've created or downloaded from the Internet. Or, you might have questions about what you've got installed—for example, do I have the libdvdcss library? Then you unexpectedly run out of space on a partition—is there some giant file filling it up that you don't know about? As another example, suppose you've just removed the account for the user dave. Presumably most of dave's files were in his home directory, /home/dave, but are there any files anywhere else owned by dave?

SUSE Linux provides both graphical and command-line tools that will let you search the filesystem (or a specified part of it) for files that meet various criteria. You can search on the filename (either a complete or partial match) or on the file's attributes, (such as its size or ownership or time of last modification), or even on a string match on the file's contents.

KDE includes a graphical tool called kfind. From the main KDE menu, select Find Files. This will display the file finder dialog, which has three tabs under which you can enter search criteria: Name/Location, Contents, and Properties. Simple name-based searches can be performed using only the Name/Location tab (Figure 2-14). Enter the name, check the Include subfolders box if you want the search to recurse down into directories below the one you start in, and click Find.

Figure 2-14: Name-based file search using kfind

The filename you enter in the Named text box can include the same *, ?, and [...] wildcard notations that the shell understands. For example, [A-Z]*.png will find files whose name begins with an uppercase letter and ends with .png.

You can combine name-based searches with searches based on the file's content using the Contents tab, and with searches based on file attributes such as ownership, size, or time of last modification using the Properties tab. (Figure 2-15 shows a search for files larger than 100 MB.) A list of all the files that were found will be shown in a scrollable window at the bottom of the tool. You can sort the files on any of the column headings displayed (name, size, and so on) by clicking on the column heading.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Mounting Filesystems

Inhaltsvorschau

One of the key differences between Windows and Linux is that Windows uses drive letters such as C: and D: and Linux does not. I have met people who are transitioning from a Windows desktop to Linux, and who are so used to drive letters in Windows that they are seriously discomfited by their absence in Linux. "How do I know where to find my stuff if there are no drive letters?" is a question I've been asked more than once. It is tempting for an experienced Linux user to dismiss such questions as naïve, but the reality is that many people come to Linux with their expectations and prejudices set by the way Microsoft does things, and those people deserve a proper explanation of why things are different in Linux (and, perhaps, why the advocates of Linux would consider it superior).

My own view (just as biased as anyone else's, in its own way) is that drive letters represent an implementation issue that should really be hidden from users. Why should I need to know which drive a file is on (or even whether it's on the local hard drive or on a network server)? Surely, I should just need to know the name of the file?

Linux provides the illusion of a single filesystem tree (even though in reality that filesystem might be spread across multiple physical disks, removable media, and network file servers) by attaching pieces of the filesystem into the overall naming tree that starts at the root (/). The operation of attaching a filesystem in this way is known as mounting, and is the subject of the rest of this lab.

A filesystem contained on a partition of a local disk drive can be mounted using a command something like this:


# mount -t ext3 /dev/hda5 /usr/local

Here, -t ext3 specifies the type of the filesystem to be mounted. The mount command will usually figure this out for itself, so this argument is often not necessary. /dev/hda5 is the partition containing the filesystem that you want to mount, and /usr/local is what's called the mount point. The mount point is usually an empty directory within the root partition created specifically for that purpose. (It is possible to mount onto a nonempty directory, and if you do, the original contents of the directory are "covered up" by the contents of the mounted filesystem and will reappear when the mount is removed, but it is not usual to do this, except by mistake.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Access Your Desktop Remotely

Inhaltsvorschau

Have you ever been in the position of trying to help someone perform some task with his or her computer, but not being physically in front of the machine? Trying to talk someone through a multistep process with a graphical user interface can be quite difficult and frustrating.

Interestingly, it's actually easier to talk a remote user through using a command line than a graphical interface because you can explicitly specify the commands rather than engaging in vagaries such as "click the little button just under the penguin."

An application called VNC (Virtual Network Computing—not the best of names) lets you access a desktop session on a remote machine. The remote machine runs a VNC server, and the local machine runs a VNC viewer. This lab explores the use of VNC to start up and access a brand new desktop session, and how to use the tool Krfb to gain shared access to an existing desktop.

VNC is a client/server application. The server (which runs on the "target" machine—that is, the machine whose desktop you want to control) is called Xvnc, and the client (which runs on the machine you're actually sitting at) is called vncviewer.

If you want to set up a desktop session that can be accessed remotely, begin by running vncpasswd on the target machine. This process will ask you for a password, encrypt it, and store it in ~/.vnc/passwd. Optionally, you can specify a "view only" password which, if you use it to connect to the target machine, will allow you to passively observe a desktop, but not actively control it.

Next, start the server using vncserver. This is a Perl script in /usr/bin. It is essentially a "wrapper" that starts the VNC server, Xvnc, with appropriate arguments.

vncserver will report the desktop number of the desktop session it has started. You will need this to connect to the session using vncviewer. In the following example, the desktop is ":1".


$ vncserver



New 'X' desktop is snowhite:1



Starting applications specified in /home/chris/.vnc/xstartup

Log file is /home/chris/.vnc/snowhite:1.log

As the preceding example shows, vncviewer reads the file

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 3: Using SUSE Linux on Your Desktop

Inhaltsvorschau

This chapter looks at SUSE Linux through the eyes of an end user (whatever that is!) and examines how to do some of the everyday things that end users do—configure the desktop to look pretty, play multimedia files, burn CDs, and so on. The assumption is that you'll be using a graphical desktop interface to do most of these things, though you'll see how to do some of them from the command line, too.

It will probably help you make sense of what's going on in some of these labs if you know a little bit about the graphics architecture in Linux first. If you are coming from a Microsoft Windows or Mac OS background, you will find it's rather different.

The key point to understand is that the Linux windowing system uses a client/server architecture. The server component, which runs on the machine where the physical user interface resides (the screen, keyboard, and mouse), is called the X server. The client components (any applications that wish to present a graphical user interface) may run on the local machine, or may be remote, as shown in Figure 3-1. In a nutshell, any time a program (such as the Firefox web browser or OpenOffice word processor) wants to put a character up on the screen or draw a picture, it has to ask the X server to do the drawing on its behalf.

Figure 3-1: X client/server architecture

The X server provides the basic capability to render text and graphical elements onto the screen and to retrieve input from the keyboard and mouse (or other pointing device). The X server provides "mechanism, not policy"; that is, it does not define a look and feel for a graphical application—that's up to the application itself and the graphical toolkit that it uses. The X server does not even provide basic window management—those decorations around a window that allow it to be moved, resized, minimized, maximized, or closed. These features are provided by a window manager, which, in terms of the client/server architecture of X, is just another client of the X server.

Newcomers to this architecture sometimes puzzle over the client/server relationships here, thinking that they're the wrong way around. People are used to clients running locally, with the servers possibly being remote. Here, the X server always runs locally, and it's the clients that might be remote. If you think about the service that's being provided (essentially just access to the physical user interface), then it makes sense.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Your Graphics Card and Monitor

Inhaltsvorschau

Getting the X server to properly drive your graphics card and your monitor used to be among the darkest magic involved with a Linux installation. Nowadays, thanks to vastly improved auto-probing of the hardware and much better configuration tools, in most cases it is a simple point-and-click process. Indeed, you were probably taken through the process by the YaST installer and already have a system working at the correct resolution. If you do, you can probably skip this lab!

SUSE Linux includes an X server configuration tool called sax2. You can run this from the main YaST screen by selecting Hardware from the panel on the left, then Graphics Card and Monitor from the panel on the right. You can also run sax2 directly from the command line; in fact, you can even run it from a terminal window without having a graphical desktop running at all. However, sax2 requires a graphical user interface and will start its own X server if it needs to. The main screen of sax2 is shown in Figure 3-2.

Figure 3-2: The main screen of SaX2

From this screen, you can set the resolution and color depth of the display. The color depth refers to the number of bits that are used to represent the color of each pixel on the display. Greater color depth gives more colors and hence greater color fidelity. A 16-bit color depth is adequate for older machines, and will often give better performance. However, if you have a recent mid-range to high-end video card, you won't take a performance hit by using 24-bit color (and you'll enjoy the full effect of the latest eye candy in GNOME or KDE). You will probably want to set the spatial resolution to the highest that your monitor is capable of (if you have an LCD monitor and you use a setting that's less than the maximum, your LCD monitor will have to scale the display, leading to unpleasant visual artifacts). Under some circumstances, if you set the resolution higher than this, you'll get a "window" (whose size is determined by the physical resolution of your screen) that you can pan and scroll around within a larger desktop (whose size is determined by the resolution you specify) using the mouse. I don't like this mode of operation.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Your Keyboard and Mouse

Inhaltsvorschau

Living, as I do, in England, it is a constant source of wonder to me that I can get on a Eurostar train in London and arrive two hours later in a country where they make strange noises with their mouths that I cannot understand. That is, they speak French. There is no directly analogous experience in the United States, though a New Yorker might try getting on a plane to Birmingham, Alabama, and attempt to hold a conversation with a taxi driver there. In addition to TV programs like Big Brother, one of the penalties of being a highly evolved species is that we have no global standard for language, except for (in the case of the Brits) shouting slowly in English on the assumption that anyone who doesn't understand that isn't worth talking to.

It is hard to know the score for lower life forms but I am prepared to bet good money that English mice and French mice have no such barrier to communication, apart, perhaps, from a minor disagreement on the relative merits of Camembert and Wensleydale. We don't even agree with the French on how to write dates, whistle the National Anthem, or lay out the keys on our keyboards. Our qwerty is their azerty. We have no idea how to put a cedilla under our c's or a circumflex over our a's.

It's not just the French. The Spanish have their own ideas how to do things. Their qwerty is in the right place, but they have these weird upside-down question marks and twiddly things (I think they're called tildes) over their letter N. Even the Yanks and the Brits disagree over keyboard layouts. Americans looking for the @ sign or Brits looking for the quotation mark over the 2 on the wrong side of the pond will be well adrift. To the Brits, a pound sign is a currency symbol like this: £. To the Americans, a pound sign looks like this: #. I once tried to explain this to a class in San Francisco and came close to being lynched in disbelief. In desperation I circulated a British banknote around the class to show what a "proper" pound sign looks like. It didn't help, though I did get the note back. If this kind of thing interests you, I recommend that you visit Michael Quinion's wonderful web site at

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure the KDE Menus and Panel

Inhaltsvorschau

The KDE desktop is customizable in almost endless detail. You can change the background wallpaper, the screensaver, the color scheme, the icons, the menus, the panel, the shortcut keys, and much else. Some of these changes bring real improvements in productivity, but in my experience, extensive tinkering with the desktop is often used as a displacement activity to avoid doing any real work. In this lab, we'll see how to customize the menus and the panel.

To customize the main menu, right-click on the main menu button at the left end of the main panel, and select Menu Editor from the pop-up menu. (You can also run kmenuedit from a command prompt.) The menu editor screen has a tree control in the panel on the left that allows you to navigate through the menu hierarchy. For the sake of a simple example, here's how to add a shortcut key to invoke the Konsole terminal window:

You already know that this application is on the menu under System → Terminal → Konsole, so navigate through the tree view control accordingly, expanding System, then Terminal, and finally selecting Konsole.
The menu editor will display the current settings for this menu entry as shown in Figure 3-7. There is probably no shortcut key currently allocated. To set one, click on the button labeled "Current shortcut key."
In the dialog labeled Configure Shortcut, make sure that the radio button labeled "Primary shortcut" is selected, then enter the key combination you want to use as the shortcut—for example, Alt-T. (Do not be tempted to use a printing character such as Shift-T. If you do, every time you try to type an uppercase T, you'll launch a terminal window!)
From the KDE Menu Editor's menu, select File → Save to save the new settings, then quit the application.

Figure 3-7: The KDE Menu Editor

As another example, let's add a new menu item. There's a handy program called top that displays a useful summary of the system load and the most resource-hungry processes currently running. System administrators find it useful for monitoring the health of busy servers. Here's how to put it on the System → Monitor menu:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure the KDE Desktop

Inhaltsvorschau

KDE users fall broadly into one of two camps: there are those who are happy to leave the look and feel of their desktop entirely alone and get on with some work, and there are those to whom it is important to have their window borders exactly the right shade of pink, see a different picture of their pet tortoise behind each virtual desktop, and hear a drum roll each time they open a window. It is to this latter group that this lab is dedicated.

Some of the most common desktop configuration options are available by right-clicking on the desktop and selecting Configure Desktop from the pop-up menu. In this tool, you can make changes in five categories, which are selected by clicking on the icons in the pane on the left.

On the Background settings screen, you can:

Set a background image for the desktop. You can either set the same background for each virtual desktop or set a different one for each. There is quite an extensive collection to choose from, or you can import your own images and use those. You can even select a "slide show," which cycles around a specified collection of images at a specified rate.
Select a color instead of a background image—either a simple solid color or a gradient between two colors.
Select a blend between a background image and a color or color gradient.

On the Behavior settings screen, you can:

Turn the desktop icons on or off.
Turn the desktop menu bar on or off. (This menu bar mostly duplicates the functions available by right-clicking on the desktop.)
Turn on a Mac OS-style menu bar. In this mode, a menu bar corresponding to the application that currently has input focus appears at the top of the desktop. This is the normal style for a Mac desktop, so if you're from a Mac background, you will probably like it; if you're not, you probably won't.
Determine the behavior of the left, middle, and right mouse buttons when clicked on the desktop.

On the Multiple Desktops screen, you can:

Set the number of virtual desktops (up to a maximum of 16, though I find 4 is the maximum I can keep track of).
Give names to the virtual desktops.

On the Screensaver screen, you can:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Lock Down the Desktop for Kiosk Mode

Inhaltsvorschau

The configurability of KDE is one of its great strengths. However, there are situations when you'd like to restrict the amount of configuration that end users can perform. Examples of this are Linux-based kiosk applications, such as an information terminal in a library or airport, computers in Internet cafés, the computer you set up for your aging (and technically inept) aunt and uncle, and even corporate desktop systems intended for nontechnical users. In this lab, you'll see how you can lock down the desktop (for example, you can prevent the user from logging out, stop them from changing the icons and files on the desktop, disable context menus, and much else besides) for these situations.

As a (completely irrelevant) aside, a Linux-loving friend of mine called Bob tells the slightly tongue-in-cheek story about setting up a computer for his elderly parents so they could do email and surf the Web, or at least paddle in it. Of course, he chose to set up a Linux system. He spent some time explaining how to use it and went away, doubtful of how well they'd manage. Over the next few weeks Bob received a lot of phone calls asking for clarification on how to do this and that, but the calls tapered off and eventually stopped altogether. Suspecting that they'd simply given up, on his next visit home he made a point of asking how they were getting on. "Oh, we're doing fine," they assured him. "Is there anything you want to ask while I'm here?" he enquired. "Well," they said, "There is one thing. Since we got a computer, we've been talking to our other friends who have computers, and there's something they seem to do a lot of that we don't know how to do." "Oh, what's that?" asked Bob. "Well," they said, "We'd like to know how to reboot."

First, you will need to install the kiosktool package (which is not installed by default). Once it's installed, launch kiosktool from the main KDE menu using System → Configuration → Kiosk Admin Tool. To use kiosktool, you begin by defining KDE profiles (a profile is basically a collection of KDE settings), and then you assign profiles to users. From the main menu of kiosktool, you can modify the existing profiles or add new ones. There are four predefined profiles:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure the GNOME Desktop

Inhaltsvorschau

Of the dozen or more desktops available for Linux, KDE and GNOME are the most mature and are certainly the only two that are decently supported and configured in SUSE Linux. Some Linux distributions (or distros) are strongly biased in favor of one or the other; for example, Ubuntu Linux strongly favors GNOME. My impression is that SUSE favors KDE, but only by a small margin. There is little point in attempting a reasoned discussion about whether KDE or GNOME is better. They're both very good, both well styled, both highly customizable, and both will let you get the job done. I will confess a personal preference for KDE, but that's probably only because I know it better than GNOME.

Overall, GNOME perhaps has a cleaner and simpler look than KDE. By default, Gnome uses two panels (task bars) instead of KDE's one: one across the top edge of the screen and one across the bottom. (However, in SUSE 10.1, the default setup has no task bar along the top edge.) By default, the top panel carries the menus and the launch icons; the bottom panel carries the window list and the virtual workspace switcher. (I keep saying "by default" because, like KDE, GNOME is endlessly customizable, which is the purpose of this lab.)

Instead of the single main menu in KDE, there are (since GNOME version 2.10) three menus on the top panel: Applications, Places, and Desktop. Applications lists all the GNOME applications. Places has links to the user's home folder, the desktop, bookmarks, all removable devices (which are mounted), network servers, and the recently used files list. Places also lets you search for files and connect to remote servers. The Desktop menu consists of submenus for desktop configuration and entries for logging off, locking the screen, and so on. (If you prefer a single menu closer to the KDE style, you can add the main GNOME menu to the panel as described next.)

To configure either the top or bottom panel, right-click on the panel and select Properties. From the panel properties dialog, you can:

Change the size of the panel.
Add hide buttons or turn on auto-hiding.
Set the background and transparency of the panel. (Personally, I can't get too excited about transparency on the desktop. Maybe I'm getting old.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Play Audio and Video

Inhaltsvorschau

Because I've grown up in an environment of "scientific" computing (and in an era when CPU cycles were always in short supply), the idea of using a computer for anything so frivolous as playing music or movies would never have occurred to me. Times have changed. In this lab, you'll learn how you can use SUSE Linux to play and manipulate digital audio and video content.

Not all of the software you'll need to turn SUSE Linux into a capable multimedia player is included in the standard distribution. If you are running SUSE Linux 9.3, there's a multimedia option pack that you should install. It is available via YOU (YaST Online Update). There is no multimedia option pack for 10.0 or 10.1. However, you might want to visit the Packman site (for SUSE 10.0, the URL is http://packman.iu-bremen.de/suse/10.0), where you will find a number of multimedia packages. You'll learn about installing packages with YOU in Chapter 5.

Playing audio CDs on SUSE Linux is a bit of a no-brainer. If you insert an audio CD, SUSE Linux should auto-detect it and offer to start the player KsCD. If it doesn't, you can start the player manually by selecting Multimedia → CD Player → KsCD from the main KDE menu.

This player is easy to use; to describe its user interface would be to insult your intelligence. The only slightly nonobvious feature is a drop-down list at the top of the KsCD screen that gives access to the track list. If you have an Internet connection, the player will automatically contact a CDDB server to obtain a track list for your CD. (Go to Extras → Configure KsCD → CDDB to select a server; the default is freedb.freedb.org.) Track lists are cached in the ~/.cddb folder.

The GNOME CD player, gnome-cd, is also available, and has, if anything, an even cleaner user interface. (Select Multimedia → CD Player → CD Player from the main KDE menu.)

Section 3.7.1.1: To rip an audio CD

For "ripping" CDs (i.e., converting the tracks into encoded audio files), use Grip. (Select Multimedia → CD/DVD tools → Grip from the main KDE menu.) Actually, Grip also functions fine as a CD player, but ripping is its main purpose. If you do not see it on the menu, try installing the Grip RPM. Grip uses a hierarchical organization of screens with a row of tabs at each level, which makes it difficult to navigate until you get used to it. I would have preferred a tree view control.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Burn Your Own CDs and DVDs

Inhaltsvorschau

Burning CDs and DVDs can be useful as a convenient and cheap form of backup, as a way of producing audio or video discs for home entertainment use, or even to produce your own Linux distribution. There are (of course) quite a number of CD-writing tools for Linux. Most of them are basically graphical frontends to the underlying command-line tools, which we'll discuss later in this lab. This lab looks at K3b, one of the best of these tools. K3b is available from the main KDE menu at Multimedia → CD/DVD burning → K3b.

We'll look at five tasks: creating a data CD, creating an audio CD, burning a CD from an existing ISO image, copying a CD, and creating an ISO image from a CD.

Section 3.8.1.1: To create a data CD

Launch K3b and select File → New Project → New Data CD Project from the menu. The Current Project window will open in the lower half of the screen. You may now navigate the filesystem and drag the files or folders that you want to include on your CD into the Current Project window. A green progress bar across the bottom of the screen shows how much space will be used on your CD. When you've completed adding files to the project, click on Burn. (If you think you're likely to want to burn the same set of files to CD again, save the project using File → Save As from the menu.) Projects are stored as XML text in zipped files with the extension .k3b. The Burn screen offers many configurable settings under five tabs. Most of these can be left alone. Settings you might want to consider changing are listed next.

On the Writing tab, you can:

Select the CD writer (if you have more than one).
Set the writing speed.
Turn off the "on the fly" option. This tells K3b to build the disk image before starting to write it, and might be helpful on older, slower machines.
Turn on the "Only create image" option. This tells K3b to create an ISO image of the CD rather than actually burn one. You might want to do this to put the image onto a web site, for example. Note that you can subsequently do a loopback mount on the ISO image with a command something like:
```
# mount -o loop mycdimage.iso /mnt
```

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Capture Screenshots

Inhaltsvorschau

Capturing screenshots (images of what you can see on the screen) is a fairly common requirement. Those of us who write books or training materials do a lot of it, of course, but it's also not unusual to want to insert some kind of screenshot into a document, or to email an image to a friend or preserve a particularly interesting web page for posterity. This lab looks at some of the tools for capturing screenshots.

If you're working with a KDE desktop, I recommend KSnapshot. It's available on the menus under Utilities → Desktop → KSnapshot. (This is not a very convenient location, so if you're planning to take a lot of screenshots, you might want to put a launch icon for it onto the main panel. Lab 3.3, "Configure the KDE Menus and Panel," shows how to do that.) KSnapshot also works fine on a GNOME desktop.

KSnapshot is easy to use. It offers a choice of three capture modes:

Full screen
Window Under Cursor (either with or without the window borders)
Region

There is also the option to delay for a specified number of seconds before taking the picture. This gives you time, for example, to get the input focus into the right window. KSnapshot automatically hides its own window while it is taking the picture.

The Region mode allows you to drag with the mouse to select the region you want to capture. (Position the cursor at the top-left corner of the region, press and hold down the left mouse button, drag to the bottom-right corner, then release.)

Once the picture has been taken, Ksnapshot displays a thumbnail of the image. You then have the option to save the image to a file or to print it. (See Figure 3-14.) Clicking Save As brings you to the Save As dialog. If you expand the drop-down list labeled Filter, you will see the image formats supported by KSnapshot. Unless you're seriously into image processing, you will probably not be familiar with most of these. For capture of a typical screenshot, the PNG format works well and offers a good compromise between image size and quality. If the image is more naturalistic (for example, a photograph), you may find that JPEG works better.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Use Command-Line Tools

Inhaltsvorschau

It may seem strange to include a lab about using the command line in a chapter about using the desktop, but the truth is, you'll benefit greatly in your use of Linux from some measure of proficiency at the command line, and you should regard the command prompt as your friend. In Chapter 2, you've already seen a number of commands for filesystem management and for creating user accounts. This lab looks at a few more useful commands and how to use them in combination. This is a very brief treatment of what is really a very extensive subject. Most books devote entire chapters to command line use. In fact, some books devote entire books to it!

To start a terminal window, select System → Terminal → Konsole from the main KDE menu. (Konsole is just one of several terminal emulators; they all do more or less the same thing, but some of them are prettier than others.) From GNOME, select Applications → System → Terminal → Konsole.

A terminal emulator is basically an application that provides a window that behaves like an old-fashioned character terminal. It provides an environment in which command-line tools can run within a graphical environment. It does obvious things like scrolling (if the text has reached the bottom line of the screen and another line is entered, the existing text is moved up one line to make room). This sort of behavior is so obvious that we take it for granted, but it does not happen by magic...it happens because the terminal emulator is written that way. Terminal emulators designed to run in graphical environments usually provide additional cosmetic features such as the ability to change the font or the background color, and the ability to cut and paste text to or from other applications. In the introduction to Chapter 2, you also saw how to get a really authentic command-line experience by dropping out of the graphical desktop entirely and using a virtual terminal.

The terminal window will automatically start a shell. "Shell" is the Linux word for a command interpreter (like a Windows "Command Prompt," but more powerful). There are several shells available for Linux; the one that will be started is specified in your account (it is the last field in the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Multiheaded Displays

Inhaltsvorschau

Multiheaded graphics cards (cards with two or more video outputs) from NVIDIA, ATI, Matrox, and others are now commonplace. Also, modern laptops can generally use their external video connector to drive a display that is independent of the display on the laptop's own screen. There are two rather different reasons why you might want two displays. The first, common on multiheaded desktop machines used for technical design or creative art work, is to provide a bigger working area, either by stretching one desktop over two displays or by having two independent desktops. The second, common on laptops, is to drive an external monitor or data projector for presentations or for teaching. In this case, you usually want the second display to be a clone of the first. In this lab, you'll see how to set up both types of dual-head configuration.

It's even possible to attach a second keyboard and mouse, and let someone else use the other display with a totally separate X session. For more information, see the "Multiple local XFree users under Linux" HOWTO at http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/.

The screen configuration is configured by SaX2 (SUSE advanced X11 configuration). From the main KDE menu, select System → Configuration → Configure X11 System (SaX2). You can also start it from the main YaST screen by selecting Hardware → Graphics Card and Monitor. The main screen of SaX2 is shown in Figure 3-18.

Figure 3-18: The main screen of SaX2

If you're familiar with SUSE 9.3, you'll notice that this screen is easier to navigate than it used to be. On the downside, this version of SaX2 appears to have dropped the option to configure two displays as independent screens.

To activate the second display, check the box labeled Activate Dual Head Mode and click Configure (see Figure 3-19).

Figure 3-19: Dual head settings

Here, you can specify the manufacturer and model of your second monitor, or select one of the generic LCD settings. You can select the resolution that the second display will run at. If possible, use the same resolution for both displays. You can also choose between cloned multihead mode or Xinerama. (There's a sci-fi B movie in there somewhere—"Curse of the multihead clones," perhaps? Shot in Xinerama, of course.) Cloned is appropriate for a laptop driving a projector; Xinerama allows you to stretch one desktop over two displays. You can also specify the spatial relationship of the two displays. In Xinerama mode, the mouse will traverse off the edge of one display onto the other.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Animate the Desktop with Xgl and Compiz

Inhaltsvorschau

Given the rapid pace of software development in the Linux world, it is inevitable that some topics that are bleeding-edge as this book goes into production will be mainstream technology by the time you get to read it. One such is the Xgl X server and the compositing window manager compiz. Together with a modern graphics card, these components (which are shipped with SUSE Linux 10.1) offer some stunning visual desktop effects comparable (dare I say this?) to the best that the Mac has to offer. These effects include transparent windows, fade-in/fade-out of windows and menus, animated window minimization, and the ability to put four desktops onto four faces of a cube and spin the cube (in 3-D) to switch desktops. The overall result is to give the desktop a more fluid, organic feel.

Of course, the command-line die-hards will consider 3-D on the desktop about as much use as a carpet in the garage. I am personally not a great fan of so-called eye-candy. But then, I don't buy decorations for my mobile phone, download polyphonic ring-tones, or wear jewelry in my navel. I think it's an age thing.

At the time of writing, this technology is running on only a limited number of platforms and you may have a rough ride working through this lab. Novell is planning to release this technology as a core part of SLED (SUSE Linux Enterprise Desktop—the new name for NLD) in Spring 2006. If you would like to see what it can do without actually installing it, there are some demo movies at http://www.novell.com/linux/xglrelease.

To get Xgl working well, it is essential to harness the 3-D rendering capabilities of your graphics card. Without that, desktop animation is desperately slow. At the present time, Xgl is working well with cards based on ATI and NVIDIA chipsets; I'll use NVIDIA as my example. NVIDIA is one of the few manufacturers of graphics chips that actually supply Linux drivers. There is an open source driver called nv included in SUSE Linux that will drive most NVIDIA cards acceptably, but to get full 3-D performance (and to run Xgl), you should install NVIDIA's proprietary driver. This driver is not included in the SUSE distribution, because it is not open source and has its own license agreement. The driver is, however, free, and may be downloaded from NVIDIA's web site,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 4: Using Linux on Your Laptop

Inhaltsvorschau

Laptops present special challenges, not only for Linux but for all operating systems. They often have special low-power versions of standard chipsets that have in the past presented a major obstacle to getting Linux installed and running properly. Nowadays, laptops are mainstream and hardware support in Linux is excellent. Nonetheless, there remain a few challenges, which I discuss in this short chapter—configuring power management to conserve battery life, using wireless and Bluetooth connectivity, and synchronizing the files on your laptop with those on your desktop system.

The term power management refers to a group of techniques that (for the most part) are designed to reduce the power consumption of a PC (particularly a laptop running on battery power). These techniques include suspend-to-disk, suspend-to-RAM, processor frequency scaling (reducing the processor clock speed), spinning down the hard disk, and thermal management (starting the fans).

Linux support for power management on laptops lagged behind Microsoft Windows support for many years. It has come a long way in the last few years; however, it is still considered experimental in the current kernel. Before playing with any of the settings here, make sure that everything is backed up.

In theory, three suspend modes are supported:

Suspend-to-disk: Saves the actual state of the machine to disk and powers it down entirely. When the machine is next booted, the previous state is restored and the computer resumes where the suspend was triggered. The ACPI term for this is ACPI S4. (Suspend-to-disk is the most reliable of the three modes and is considered "mainstream." It works fine on my laptop; however, it's the slowest to suspend and resume.)
Suspend-to-RAM: The machine state is saved in RAM, most of the devices in the computer are powered down, and only the memory is powered to keep its contents. The ACPI term for this is ACPI S3. Suspend-to-RAM is still considered experimental. On my laptop, the suspend is very quick, but unfortunately the machine won't come back up again without forcing a power on/off cycle. Your mileage may vary.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Laptop Power Management

Inhaltsvorschau

In theory, three suspend modes are supported:

Suspend-to-disk: Saves the actual state of the machine to disk and powers it down entirely. When the machine is next booted, the previous state is restored and the computer resumes where the suspend was triggered. The ACPI term for this is ACPI S4. (Suspend-to-disk is the most reliable of the three modes and is considered "mainstream." It works fine on my laptop; however, it's the slowest to suspend and resume.)
Suspend-to-RAM: The machine state is saved in RAM, most of the devices in the computer are powered down, and only the memory is powered to keep its contents. The ACPI term for this is ACPI S3. Suspend-to-RAM is still considered experimental. On my laptop, the suspend is very quick, but unfortunately the machine won't come back up again without forcing a power on/off cycle. Your mileage may vary.
Standby: Processes are stopped, and some hardware is deactivated. The ACPI term for standby is ACPI S1. On my laptop, this works and is quite quick, but the LCD screen is not powered down.

Because these features are still experimental, you need to enable them explicitly in YaST. From YaST's main screen, select System from the left pane, then Power Management from the righthand pane. On the main Power Management Settings screen, click Suspend Permissions. Here you can specify which of the three modes to allow. To exit, click OK and then Finish.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Wireless Networking

Inhaltsvorschau

Wireless networks in Linux are one of those areas that generally either work perfectly straight out of the box, or don't work straight out of the box and give you hours of grief. This lab is mostly dedicated to the poor souls (like myself) whose experiences fall into the second category.

From the YaST main screen, select Network Devices from the pane on the left, then Network Card from the pane on the right. From the command line, you can go straight to the screen you need with:


# yast2 lan

If your wireless card shows up in the list at the top (see Figure 4-2), then the odds are good that you are going to belong to the first, luckier group of people. It's not completely plug-and-play, though—most cards need firmware loaded to make them work, because most wireless LAN manufacturers don't put the intelligence into the actual driver. How you obtain and load the firmware depends on the card. Some cards will prompt, as you configure them to install the appropriate RPM, others will require a download via YOU (YaST Online Update), and some may require that you manually track down the firmware.

Figure 4-2: YaST wireless card configuration—main screen

To configure your card, select it from the list and click Edit. In the case of the Intel IPW2200 card shown in Figure 4-2, YaST will prompt you, if necessary, to install the RPM that contains the firmware binaries. This should be included on your installation media. An RPM containing firmware for the Atmel AT76C50X card is similarly available.

For "legal reasons" (I am left pondering the concept of an "illegal reason"), firmware for other wireless cards is not included in the distribution but is available via YaST Online Update. (See Lab 5.5, "Perform an Online Update" for information about YOU.) This includes firmware support for ACX100, ACX111, and PrismGT wireless LAN cards.

Once the firmware is downloaded, you'll see the standard YaST network configuration screen. Here you can configure your IP address settings (probably you'll want Automatic). Clicking Next will get you to the wireless configuration screen, shown in Figure 4-3.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Bluetooth Devices

Inhaltsvorschau

Bluetooth is a short-range wireless protocol used to connect devices such as mobile phones, PDAs, and computers. It is named, so I'm told, after King Harald Bluetooth, who united Denmark and Norway. (This was back in about 950 AD, so you may be forgiven if your memory of it is hazy.) Anyway, the idea is that Bluetooth as a personal network technology can unite digital devices.

In reality, there can often be problems getting your phone working with your hardware and doing everything that the feature list says it should be able to. This is true for Windows as well as Linux. There are many features that may work on Bluetooth, and potentially many devices you might interact with, but in this lab we'll concentrate on interacting with a phone. That should be enough to get you going with other Bluetooth-enabled devices.

First things first—check to see whether your laptop or PC has recognized the Bluetooth device. Many laptops now come with these as standard, but if not, you can also get USB-capable Bluetooth devices, which generally work fine. You should also make sure you have the packages bluez-libs and bluez-utils installed. (Bluez is the Bluetooth protocol stack used by SUSE.)

To configure Bluetooth using YaST, from the main YaST screen click on Hardware in the panel on the left, then Bluetooth in the panel on the right. This will bring you to the main Bluetooth screen shown in Figure 4-5.

Figure 4-5: The main YaST Bluetooth Configuration screen

On this screen, you can enable the Bluetooth service. You also need to enter the name your laptop will be known as. There are a couple of shorthand items that you can use here: %h stands for the hostname of the system, and %d stands for the interface number (in case you have more than one Bluetooth adapter). On this screen you can also enter the PIN code that your laptop will ask for whenever a device is trying to connect with it, or you can configure it so that it always asks you for a PIN. This option allows you to use different PINs for different devices.

If you click on Advanced Daemon Configuration, you can configure the various Bluetooth services (called

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Synchronize Files with Your Desktop

Inhaltsvorschau

I envy people who have only one computer. (Sometimes I really envy people who don't have a computer at all, but that's another story.) Those of use who routinely use two (or three, or four...) computers face the problem of synchronization—making sure that the most recent version of whatever document we're working with is actually on the machine we're working at. Without tools to help, it's very easy to lose track of where things are and discover you've just spent an hour editing a file that's two weeks out of date compared to the copy on your other computer.

Data synchronization between two or more machines can be tricky to manage. There's the problem of how to actually copy the data from one machine to another, and then there's the problem of deciding which files actually need to be copied. The first problem is easily solved; using tools like scp and rsync, it's quite easy to move data around. Deciding what needs to be copied is harder, and traditionally requires the discipline to update your central repository every time you update a file—otherwise, you may update a file in two places, and then you are almost bound to lose data.

Novell sells a mature synchronization product called iFolder. Using iFolder, users keep personal data files within one or more nominated directories (which they call their iFolders) on their personal machine(s). At regular intervals (usually every few minutes), their iFolder client connects to the iFolder server (which maintains a central repository of their iFolder files) and figures out which files have been updated and need to be uploaded or downloaded. Of course, even when the personal machine is offline, the local copies of the files continue to be available. Multiple users can subscribe to the same iFolder, so that the product allows file sharing amongst user communities who are often working offline. Beyond some initial setup, the service is completely automatic and needs no intervention. This commercial product is based around a closed source server and open source clients. However, iFolder3 is an open source server implementation that runs on Mono (in case you don't know, Mono is a cross-platform implementation of Microsoft's .NET Framework). iFolder3 is still in early development, and it is significantly more limited than the commercial server from Novell, but it should do the job.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 5: Package Management

Inhaltsvorschau

I am not a follower of fashion. I prefer to think that fashion is a follower of me. In reality, what happens is that fashion goes in cycles while I remain stationary. Once per cycle, roughly every 15 years, I come briefly into fashion and then pass out again, in much the same way that a clock that has stopped is right twice a day. All of which is by way of introducing the observation that Linux users tend to be followers of software fashion. They love to load the newest applications and try out the latest cool stuff simply because it is the latest cool stuff.

The labs in this chapter will show you how to find new packages, how to install them, how to find out what's already installed, and how to build applications from source. The underlying package management technology is RPM, but there are several fancy package management tools that build on top of this, as you'll discover.

The most common format in which software packages are made available for SUSE Linux is a package format called RPM, which originally stood for "RedHat Package Manager" because it was developed by Linux distributor RedHat, but now stands for "RPM Package Manager" because it is used by many Linux distributions. RPM is not the only package format around; another popular format is the one used by Debian Linux (usually called .deb packages), which has many ardent supporters. There are other formats used to distribute software—in particular, .tar archives ("tarballs"), which are more often used to distribute source code. (See Lab 5.8, "Compile and Install Source Code," later in this chapter.) Other versions of Unix have their own formats, such as the pkgadd format used by Solaris.

SUSE Linux, however, uses RPM, and in a sense a SUSE Linux distribution can be regarded simply as a large collection of RPM packages.

In addition to the actual files, an RPM package contains a number of components of metadata, including:

A collection of files that will be installed on the system; that is, the actual contents of the package.
A brief text description of what the package is and does.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Find Out What's Installed

Inhaltsvorschau

SUSE Linux, however, uses RPM, and in a sense a SUSE Linux distribution can be regarded simply as a large collection of RPM packages.

In addition to the actual files, an RPM package contains a number of components of metadata, including:

A collection of files that will be installed on the system; that is, the actual contents of the package.
A brief text description of what the package is and does.
Information about the dependencies of the package (the components that must already be installed in order for the package to work) and the capabilities that this package provides.
Pre-install and post-install scripts (for example, a script to add an entry for the package to the desktop menus), and also pre-uninstall and post-uninstall scripts.
A digital signature that can be used to verify the authenticity of the package if you have the public key of the package's author. This provides a way to verify that the package has not been corrupted, either accidentally or maliciously, since the time that the author signed it.

There is a command-line utility called (unsurprisingly) rpm that allows you to query, install, upgrade, and uninstall software packages. This lab will concentrate on querying packages—both those that are already installed and those that are sitting on the distribution CDs waiting to be installed. Later labs deal with installation and removal of packages.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Finding the Packages You Need

Inhaltsvorschau

Abbe d'Allainval once wrote a play called An Embarrassment of Riches. I don't know exactly when he wrote it, but it couldn't have been very recent because he died in 1753. Since then, his phrase has been widely quoted. It is sometimes translated (the original was in French) as "The more alternatives, the more difficult the choice." The vast amount of open source software available for Linux certainly represents an embarrassment of riches. Given the power of the Internet search engines, finding stuff is not hard. Finding stuff that actually works can be more of a challenge.

This lab looks at some of the places you can find software for SUSE Linux.

This is not a particularly exciting or inspired thing to say, but the first place to look for additional packages is on the SUSE Linux distribution CDs. The packages you'll find there are, by definition, built for your Linux distribution and will almost certainly work. The YaST package manager offers the easiest way to query the available packages because it knows about all the packages in the distribution. (See Lab 5.3, "Install and Upgrade RPMs," later in this chapter.) Alternatively, you can browse the CDs directly. Each SUSE CD contains a file called ls-lR.gz, which is a compressed (gzipped) recursive directory listing of the contents of all the CDs. To make it easier to browse for packages, you can copy this file into your home directory and unzip it:


$ cd /media/disk

$ cp ls-lR.gz ~

$ cd ~

$ gunzip ls-lR.gz

Now you have a file called ls-lR that you can easily search (using grep, for example) to see what packages are available. For example:


$ grep amarok ls-lR

-rw-r—r--  3 root root  5813077 Mar 23 19:22 amarok-1.2.2-5.i586.rpm

-rw-r—r--  3 root root    15248 Mar 23 19:22 amarok-xmms-1.2.2-5.i586.rpm

-rw-r—r--  3 root root    13032 Mar 23 19:22 amarok-libvisual-1.2.2-5.i586.rpm

There are other ways you could get this information. For example, you could use zgrep (a version of grep that can peek into compressed files) on the compressed file itself. Also, you could do an actual recursive directory listing of each CD and store the results in your home directory (for example

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Install and Upgrade RPMs

Inhaltsvorschau

When you initially install SUSE Linux, you get the opportunity to choose which packages you want to include. Realistically, though, if you're new to Linux, you will probably have little idea at that stage of what you want to install beyond the vague knowledge that, for example, "I want to install a KDE desktop system." Fear not...it is easy to install additional packages at a later stage. And, of course, one of the joys of using an open system like Linux is that there are literally thousands of third-party packages out there waiting to be installed and explored. This lab shows you how to install new software in the form of RPM packages.

From the command line, the simplest thing is to use rpm -i. For example:


# cd /media/SU100_001/suse/i586

# rpm -i autotrace-0.31.1-369.i586.rpm

In many cases, that's all there is to it! Note that the name SU100_001 is specific to this example. Your mileage may vary.

Using the -i option, the rpm command will refuse to install a package that's already installed. There's also the -U (upgrade) option, which will automatically remove the previous version of the package before installing the new one. If there is no existing version of the package, -U behaves like -i. Some users prefer to use -U all the time and ignore -i. The -v and -h options are also useful in conjunction with -i or -U, as they provide a simple progress report so that you're not left wondering whether the system has crashed if you're installing a large RPM. Putting these together, you may prefer to use a command such as:


# rpm -Uvh autotrace-0.31.1-369.i586.rpm

to install a package.

The rpm tool will check that all the dependencies required by the package are present; if they are not, it will report the error and abandon the installation. For example:


$ rpm -i  ImageMagick-devel-6.1.8-6.i586.rpm

error: Failed dependencies:

        libtiff-devel is needed by ImageMagick-devel-6.1.8-6

        libjpeg-devel is needed by ImageMagick-devel-6.1.8-6

        liblcms-devel is needed by ImageMagick-devel-6.1.8-6

It's now left up to you to locate the missing packages. In this case, it turns out to be easy because they are on the SUSE DVD in the same directory, so you can just install them all in one command like this:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Remove Software Packages

Inhaltsvorschau

I find that removing software packages is a far less common activity than installing them. After installing, say, SUSE Linux 10.0, I gradually accumulate more and more packages installed on top of the base distribution. Usually, this process continues until I decide to upgrade to a later distribution. There is an analogy here with moving into a new house. Once you've "moved in" to one particular distribution, you proceed to make it your own: customizing your desktop, adding new packages, and so on, until the time comes to find a new house. At that point you throw all the excess baggage away so that you can make a fresh start in your new life in your new home.

I can think of two reasons why you might want to explicitly delete software from your machine. The first is if you're running out of disk space. (This is less common in these days when you can buy a gigabyte of disk space for less than the cost of a beer.) The second is if you're especially security-conscious and want to harden your system by removing unnecessary software and services.

From the command line, you can uninstall a package using rpm -e. For example:


# rpm -e xosview

Dependency checking kicks in for package removal as well as for package installation. The xosview package is easy to remove, because nothing is dependent on it. It is at the end of the food chain—nothing dies of starvation if xosview is removed. In many other cases, life is not so simple. In this next example, I have chosen the m4 package, more or less at random, for removal. (Of course I'm sure that you've got more sense than to delete packages at random just for the fun of it.)


# rpm -e m4

error: Failed dependencies: 



        m4 = 1.4.2 is needed by (installed) autoconf-2.59-80

        m4 is needed by (installed) bison-1.875-55

        /usr/bin/m4 is needed by (installed) lsb-2.0-8

The rpm tool refuses to remove the package because other installed packages depend on it. It's possible (but not recommended) to explicitly disable the dependency check with the --nodeps flag:


# rpm -e --nodeps m4

Of course, you can do the same things using the YaST package manager. To delete a specific named package, select the Search filter and type in the name of the package, such as

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Perform an Online Update

Inhaltsvorschau

SUSE maintains web servers that contain patches and updates for the various SUSE Linux products. These servers are mirrored at various sites around the world, providing an effective way to obtain the latest patches and updates. In particular, it helps to ensure that you are not running versions of software that have known security vulnerabilities. The YaST module that interacts with this service is call YaST Online Update (YOU).

From the main YaST screen, select Software from the left pane, then Online Update from the right pane. On the main Online Update screen, choose an FTP server from the drop-down list. You can also set up your own update server (perhaps on the corporate network) and add it to the list by clicking on New Server. It is also possible to supply updates on CD or DVD.

Once you've selected an update source, click Next. YaST will download a list of updates from the server and display them. In Figure 5-5, the list on the left shows the available patches and their sizes. Security-related patches are shown in red, recommended patches in blue, and optional patches in black. If you select an item from this list, a description of the patch and its purpose is shown in the pane below, and a list of the packages that make up the patch is shown in the pane on the right (a patch can include several packages—you must install all the packages in the patch). This screen is really just the YaST Package Manager screen that you have seen in other labs.

Figure 5-5: YaST Online Update (YOU)

Use of the term patch has become somewhat confused within SUSE. In traditional Unix parlance, a patch is a set of deltas (changes from the original or prior version) or diffs that can be applied to a file to create a later version of the file. Patches were popular in the BB (Before Broadband) era, as they saved lots of time compared with downloading the entire file. In the current context, a patch just means a related collection of package updates. Just to make life more confusing, there are such things as patch RPMs, which are patches in the original sense, so that downloading an update to (say) the kernel sources downloads only a very small amount of data.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Manage Software Packages Using ZENWorks

Inhaltsvorschau

Novell has traditionally supported two solutions for package management and online package updates: there was the YaST package manager, which came from SUSE, and there was Red Carpet, which came from Ximian. Other package repository "standards" are in use, including YUM and Open Carpet. In SUSE 10.1, the YaST package manager (described elsewhere in this chapter) remains. The original Red Carpet client, which was shipped with Novell Linux Desktop, is not included in current SUSE Linux distributions. With SUSE 10.1, Novell has provided a new package manager resolver library called libzypp. The new library handles YUM metadata, YaST sources (via FTP, HTTP, NFS, or SMB), and also Zenworks, Open Carpet, and Red Carpet Enterprise (RCE) repositories. Along with libzypp comes a command-line tool called rug and three graphical tools called zen-installer, zen-updater, and zen-remover, together with the underlying zmd daemon. It is these tools that I'll be looking at in this lab.

It takes a little time to get your head around rug due to its large number of subcommands. Most of the command names have a long form, such as file-list, and a short form, usually two letters, such as fl. Table 5-2 lists some of these commands. It is not a complete list, and you should consult the manpage for a full description.

Table 5-2: Important rug subcommands
Command	Short form	Description
catalogs	ca	List the catalogs available for the services you have added.
subscribe	sub	Subscribe to the specified catalog.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Manage Software Packages Using YUM

Inhaltsvorschau

Yet another package management tool that is becoming increasingly popular is YUM. (Apparently, it stands, for "Yellow Dog Updater Modified." Yellow Dog is a version of Linux for the Power PC.) YUM is available for SUSE Linux and looks set to become the package management tool of choice. In this lab you'll see how to use it.

First, you'll need to install the packages yum, kyum, and yum-utils. (No, you can't install them with yum. You'll have to make do with YaST!) As you may have guessed, yum is the command-line tool and kyum is the graphical frontend.

YUM needs a little bit of setup—it doesn't just work out the box. Its primary configuration file is /etc/yum.conf (run man yum.conf for the details). In here, you need to specify the URL for at least one repository. (A repository is a prepared directory or web site or FTP server that contains software packages and index files.) Alternatively, you can define your repositories in separate .repo files in a specified directory. In the default installation of yum, the config file contains a few basic settings and the line:


reposdir=/etc/yum.repos.d

which tells yum to read repository information from the files in /etc/yum.repos.d; however, in the default installation, this directory is empty. I created two files in here. The first, which I called base.repo, defines a repository called base:


[base]

name=SUSE LINUX 10.0 - Base

baseurl=ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse

mirrorlist=/etc/yum.repos.d/base.mirrors

enabled=1

The baseurl= line specifies the URL for this repository, and the mirrorlist= line names a file that contains alternative URLs that provide mirrors of this repository. When yum is downloading packages, if one of the servers isn't responding, it will automatically switch to a different mirror from the list. This is a very useful feature (and one that YaST doesn't support).

The second file base.mirrors is just a list of URLs, which looks something like this:


ftp://ftp.rz.uni-wuerzburg.de/pub/linux/opensuse/distribution/SL-10.0-OSS/

inst-source/suse

ftp://ftp.uniroma2.it/Linux/opensuse/distribution/SL-10.0-OSS/inst-source/suse

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Compile and Install Source Code

Inhaltsvorschau

Installing prebuilt binary packages, as I discussed in Lab 5.3, "Install and Upgrade RPMs," is a fine way to extend your SUSE Linux distribution. However, sometimes you'll come across an application for which no binary package is available.

The distinction between a binary (machine code) package and a source package is important. A binary package includes one or more executable binary programs—files that contain machine code for a specific processor such as a Pentium, or a SPARC, or an IBM Z-series mainframe. The machine code contained in these packages consists of instructions that can be executed by a specific processor. A binary package built for one processor architecture won't work on another. A source package, on the other hand, contains files of source code written in a specific programming language (often the C language in the case of Linux applications). These files cannot, as they stand, be run on any processor at all. They need to be translated (compiled) into machine code for a specific processor. To do this, you need to have the appropriate development packages installed on your machine.

Some people are put off the idea of installing from source, thinking that they will need to look at, and understand, the source code of the applications they are installing. This is hardly ever the case. There is a standard sequence of commands, discussed in this lab, that will build most source packages on your Linux platform. It is not really any more complicated than the commands needed to install a binary package. In the (unlikely) event that you start seeing incomprehensible error messages from the compiler as you try to build the package, my advice is: if you can't figure out what's wrong within 15 minutes, give up! Unless you're a seasoned developer, you have little chance of fixing it (and even if you are, you'd probably just cut and paste those error messages into a bug report anyhow). Lest you become discouraged by this, I should emphasize that most source packages will build without any difficulty on your SUSE Linux distribution.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 6: System Administration for Servers

Inhaltsvorschau

Although the popularity of Linux on the desktop is growing, it is as a server platform that Linux has its most firmly established market niche. The flexibility and openness of Linux, its relatively small hardware footprint, its good reputation for security, and its extensive support for a wide variety of network services make it a popular server platform. Of course, the fact that it's free helps, too!

This chapter discusses the "infrastructure" for a Linux server. It will examine the mechanics of service startup; the management of disk space through the use of partitions and logical volumes; the importance of logging, tools for monitoring system activity, load, and performance; and some network configuration and debugging issues. Chapter 7 continues the story by discussing key application-level services in detail.

In some sense, this chapter marks a transition into a more professional view of Linux. However, I hope that the enthusiastic desktop user will also find useful information here.

Chapter 2 examined the early stages of the boot process, but left the story at the point where the kernel was up and running and had launched a program called init. This lab picks up the story at that point, showing how to determine which services are started by init at boot time.

Central to the operation of init is the concept of a runlevel. The runlevel determines which services should be running. The basic idea is that the higher the runlevel, the higher the level of activity in the system; that is, the more services that are running. The runlevels are defined as shown in Table 6-1.

Table 6-1: System runlevels
Runlevel	Description
0	System is halted.
S	Single user. This runlevel is useful for filesystem maintenance because no processes (except a command-line shell) are running, so the filesystem is quiescent.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Control Boot-Time Service Startup

Inhaltsvorschau

Table 6-1: System runlevels
Runlevel	Description
0	System is halted.
S	Single user. This runlevel is useful for filesystem maintenance because no processes (except a command-line shell) are running, so the filesystem is quiescent.
1	Single user.
2	Local multiuser mode without networking. "Local multiuser" really makes sense only in the context of a machine with multiple terminals attached (via serial lines for example), which is rare these days. This runlevel brings up login prompts on these terminals as well as the main console.
3	Full multiuser mode with network services running, but no graphical login manager. This is the runlevel typically used by a "headless" Linux server (one that you're running without a graphical desktop).
4

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Start Services on Demand

Inhaltsvorschau

The traditional way of providing a network service is to start the service at boot time (as discussed in Lab 6.1, "Control Boot-Time Service Startup"), and leave it running the whole time. The server creates a socket, binds its well-known port number (such as port 80 for WWW servers) to that socket, then waits for a connection request. The server process blocks (sits around waiting for something to do) at that point and may well remain blocked for a very long time, until a client comes along. The daemon xinetd provides an alternative approach by listening for connection requests on behalf of other services, and only starting the services up on demand. This approach has a number of advantages:

It prevents having many idle processes hanging around in the machine. Idle daemon processes aren't consuming CPU time but they are consuming memory (or swap space, if they're swapped out) and they are taking up a slot in the kernel's process table.
It makes life slightly simpler for the actual daemon. Instead of creating a socket and accepting a connection on it, the daemon simply inherits the network connection on its standard input and standard output.
It provides a level of access control to the services.
It supports uniform logging of service access.

xinetd replaces an earlier daemon called inetd, which was used in some earlier versions of SUSE Linux such as SLES8, but which is now effectively obsolete. In this lab you'll see how to configure xinetd.

First of all, if you're going to use xinetd, make sure that it is configured to start at boot time, for example using the YaST runlevel editor described in Lab 6.1, "Control Boot-Time Service Startup." Note that if xinetd starts up and discovers that it has no services enabled at all, it will shut down again. This is likely to be the case for a default installation of SUSE Linux, so you'll need to enable at least one service before xinetd will start up properly.

To access YaST's xinetd configuration module, from YaST's main screen select Network Services from the panel on the left, then Network Services (xinetd) from the panel on the right. This will bring you to the main

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Create and Mount Disk Partitions

Inhaltsvorschau

When SUSE Linux is initially installed, it normally creates at least two partitions on the hard drive—one for the filesystem (the root partition) and one for swap space. More complex partitioning schemes are discussed in Chapter 9. The time may arise, however, when you wish to create additional partitions, perhaps to put disk space that was left free at install time into use, perhaps because you've added a second drive to your machine, or maybe—just maybe—because you've decided it's time to get rid of that Windows partition you've left lying around and put it to better use.

The system used in this lab was originally installed with a 10 GB partition (/dev/hda1) as the root partition, and a 1 GB swap partition (/dev/hda2). The total disk capacity was 38 GB. It was decided to create another 5 GB partition to use as the /home partition for the users' home directories. There were already some user accounts, with content under /home; initially, of course this content was on the root partition.

Partitions are most easily created using YaST.

In the main YaST screen, click System in the panel on the left, then Partitioner in the panel on the right. This will bring you to the Expert Partitioner screen which will show your existing partition structure. From this screen, click Create. Depending on how many partitions currently exist, you may be asked whether you want to create a primary partition or an extended partition. (As discussed later in this lab, you can create a maximum of four primary partitions or three primary and one extended.) As there are currently only two partitions defined, you'd create a third primary partition.

Now you'll see the partition creation screen shown in Figure 6-4.

Figure 6-4: Creating a primary partition with YaST

Linux supports several filesystem formats. (The filesystem format refers to the underlying data structures kept on the disk. All these formats present themselves to the user in the same way, as a hierarchy of folders and files.) Click the Format radio button and select the filesystem type you want to create from the drop-down list labeled File System. The choices are:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Create Logical Volumes

Inhaltsvorschau

The problem with fixed-size disk partitions, discussed in Lab 6.3, "Create and Mount Disk Partitions," is just that: they are of fixed size. If your system usage outgrows a particular disk partition, you will need to save the partition's contents somewhere (perhaps by copying a tar archive across the network to another machine), create a larger partition, then restore the tar archive onto it. Even creating a larger partition can be tricky—you can't just grow a partition, unless it happens to be followed by free space on the disk, in which case you can delete the existing partition and create a bigger one.

Logical volumes provide a more flexible way of managing and allocating disk space. Using logical volumes, you create one or more physical disk partitions (they don't all need to be on the same drive) and allocate them to a volume group. The volume group represents a "pool" of disk space out of which you can carve some logical volumes. Then you create filesystems on the logical volumes and mount them into the directory hierarchy. At a later date, if part of the filesystem outgrows its logical volume, you can simply pump some more space into the logical volume from the free space available in your volume group. In other words, you can defer the decision about how much space is allocated to each part of your filesystem hierarchy, and extend the logical volumes as required. The relationship between physical partitions, volume groups, and logical volumes is illustrated in Figure 6-9.

Figure 6-9: Logical volume architecture

Let's be quite clear about how logical volumes do and don't help. They do provide greater flexibility in allocation of disk space to filesystems. They don't provide improved reliability; indeed, if a logical volume spans multiple partitions, a problem on any of the partitions is probably going to lose you the entire volume. Also, logical volumes do not (primarily) improve performance, although a logical volume striped across multiple hard drives may show improvement in I/O bandwidth.

The logical volume management tools are contained in package

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Monitor and Manage Processes

Inhaltsvorschau

Every running program in a Linux system runs within the context of a process. It's important to understand the distinction between a program and a process. A program is a comparatively concrete thing—it's a sequence of instructions telling the computer what to do. A process is more abstract—it's the thing that holds together the context needed to execute the program. The context includes the memory regions that hold the program's code and data; open file descriptors such as standard input and standard output; a list of variables known as the environment; a priority that determines how favored it will be by the scheduler; a user ID and a group ID that define the identity with which the process is running; a current directory; and a few more technical things like the signal-handling settings. Indeed, in a sense, this collection of items is the process.

From a user's perspective, processes get started in several ways (from the kernel's perspective there is only one way—through the execution of a fork( ) system call). Some processes are started at boot time to run the daemons that provide network services. Others are started by users by selecting an item from a menu or typing a command in a shell. Some applications create multiple processes of their own, often for performance reasons. When a new process is created, the process that did the creating is called the parent, and the new process is called the child.

Processes are the lifeblood of Linux. As you work on the computer, they come and they go. As I write this, my laptop is running 93 processes, and it isn't really doing anything! For the most part, you don't need to be aware of process activity, but when things aren't behaving, it helps to know your way around. In this lab, you'll see how to examine process activity and how to manage processes. As with the other labs, I show both the graphical utilities and the command-line tools.

KDE provides a nice graphical tool called KDE System Guard. (I have no idea why it's called that—by no stretch of the imagination does it guard the system.) From the main menu select System → Monitor → Performance Monitor. Alternatively, you can start it by typing

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Examine and Manage Logfiles

Inhaltsvorschau

Many Linux utilities, especially the network services, write information about their activities to various logfiles. In conformance with the FHS (Filesystem Hierarchy Standard), the logfiles are in /var/log or in subdirectories thereof. Some logfiles are overwritten each time the service starts; others simply grow without limit unless steps are taken to manage them. If the system is misbehaving, logfiles can provide vital clues to the cause. They can also provide evidence of attempts to breach system security.

In my experience, there are a couple of problems with logfiles. First, they contain a great deal of "noise" (messages of no importance), which makes it hard to find the few significant entries that are present. Second, there seems to be a particular brand of obfuscation that application developers reserve for the messages they write to logfiles—in other words, they are hard to understand.

This lab looks at some key logfiles, mentions some tools that can help analyze and manage the logs, and shows how to configure the logging behavior.

Table 6-9 shows some of the key logfiles you'll find in /var/log.

Table 6-9: Selected logfiles
Logfile	Content
boot.msg	Contains boot-time messages from the kernel and (towards the end) reports of service startup. It is overwritten each time the system is booted. Most of this is low-level rumbling inside the kernel, which won't make much sense to most of us.
faillog	Contains failed login attempts. This is a binary database and should be examined with the `faillog` command.
firewall

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Monitor System Load and Performance

Inhaltsvorschau

Linux makes available an enormous amount of performance and system load information, through the /proc filesystem and in other ways. This includes data on CPU utilization, memory and swap space usage, network traffic, and disk I/O activity. A careful analysis of this data, obtained under conditions of typical or heavy system load, can help find performance bottlenecks and identify how a redistribution of load, or a well-chosen hardware upgrade, can improve system performance.

Most of the raw statistics are low-level, detailed, and difficult to interpret. This lab looks at a number of the tools that are available to present the data in a more readily digested form.

You have already met KDE System Guard, in Lab 6.5, "Monitor and Manage Processes," earlier in this chapter. There you saw how to use its process table display as a way of monitoring and killing processes. Here, you'll get familiar with its role as a system load monitoring tool.

Launch KDE System Guard from the main menu via System → Monitor → Performance Monitor. The program displays system load information via a "worksheet"—a collection of displays arranged in rows and columns, as shown in Figure 6-17. The program uses the metaphor of a sensor, analogous to a thermometer or an oscilloscope probe monitoring a signal on a circuit board. A wide range of sensors, covering CPU load, memory use, and load average, is available.

Figure 6-17: KDE System Guard displaying system load

Several display formats are available:

Scrolling signal plotter: This is probably the most useful format, because it provides an historical record.
Digital multimeter display: The sensor value is simply displayed as a number.
Bar chart: The sensor value is represented by the height of the bar.
Sensor logger: The sensor values are written to a file. Each line of the file contains a date and time, the host name, the sensor name, and the sensor value.

All of the display types appear in Figure 6-17. Each display updates at regular intervals. You can set the update interval separately for each display, but by default the entire worksheet updates every two seconds.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Backup and Restore Filesystems

Inhaltsvorschau

It has been said that system administrators fall into one of two categories—those that perform regular backups, and those that wish they had.

I have lost files for a number of reasons. I have hard disks fail catastrophically. I have accidentally deleted the original copy of a directory full of user files, instead of the (very old) backup copy. Most spectacularly, I once caught my foot in a network cable plugged into my laptop and pulled the whole thing onto an (uncarpeted) floor. When I was a product manager for a large training company, my authors would regularly report data loss due to all sorts of reasons ranging from lightning strikes to a toddler dropping a loose hard drive into the toilet. Interestingly, the probability of such events peaked sharply a week or two prior to a deadline.

There are several options for creating backups of your SUSE Linux system, including:

You can manually create (and optionally compress) a tar archive of any desired set of files and directories. The archive can then be copied onto another machine, (using scp for example) or burned to a CD. It's also possible to perform incremental backups using tar.
You can burn a part of the filesystem directly to CD.
You can use the YaST backup tool.

Let's look at each of these in turn.

Creating a compressed tar archive is a simple but effective option. You will need either enough free space in the filesystem to hold the archive, or access to free space on a file server, using NFS for example. (To learn how to burn files to CD, see Lab 3.8, "Burn Your Own CDs and DVDs." To learn how to export and mount filesystems using NFS, see Lab 7.3, "Share Files Using NFS.") In any event, you must end up with the archive residing somewhere other than the machine you're backing up. Leaving the archive on the same hard drive as the files you're backing up is just silly.

For example, to back up the home directory of user simon:


# cd ~simon

# tar cjpf /tmp/simon.tar.bz2 .

When using tar it is, in general, best to cd to the directory you want to archive and specify . as the directory to archive, as in the example just shown. This makes it easy to restore the archive to a different directory, should you wish. The meaning of the flags on tar are shown in Table 6-12.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure and Debug Network Interfaces

Inhaltsvorschau

In Lab 1.4, "Configure a Network Card," you saw how to use YaST to perform basic network card configuration—setting its IP address, and so on. This lab examines the command-line tools for doing these things, and also some tools for diagnosing network-related problems.

You can configure a network card "just for now" with the ifconfig command. (By "just for now," I mean that settings you establish in this way won't survive a reboot. Indeed, they won't even survive if you restart the networking.) Table 6-13 shows some sample commands.

Table 6-13: Sample ifconfig commands
Command	Description
# ifconfig eth0 down	Disable the interface
# ifconfig eth0 up	Enable the interface
# ifconfig eth0 192.168.1.44	Set the IP address
# ifconfig eth0 netmask 255.255.255.0	Set the subnet mask

Running ifconfig with no arguments will show you your current configuration. Note that you don't have to be root to do this:


$ /sbin/ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0D:56:78:CD:BF

          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:7 errors:0 dropped:0 overruns:0 frame:0

          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:777 (777.0 b)  TX bytes:1712 (1.6 Kb)

          Interrupt:11



lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:729 errors:0 dropped:0 overruns:0 frame:0

          TX packets:729 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:89323 (87.2 Kb)  TX bytes:89323 (87.2 Kb)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure Name Resolution

Inhaltsvorschau

When you enter a URL such as www.oreilly.com into your browser, the browser converts this name to an IP address. When you use a command such as:


# chown chris foo

the chown command looks up the username chris to get the corresponding UID. These are examples of name resolution. Linux uses a number of "maps" that support such lookups (including those shown in Table 6-15).

Table 6-15: Linux resolver maps
Map	Principal use
passwd	Maps user names to UIDs. The map is also used (in reverse) by programs such as `ls -l` to map from the owner's numeric UID (found in the file's inode) to the username.
group	Maps group names to GIDs.
hosts	Maps host names (such as "`www.novell.com`") to IP addresses (such as "130.57.4.27").
services	Maps service names (such as "smtp") to port numbers (such as 25). For example `xinetd` consults this to find out what port numbers to listen on for each service.
protocols	Maps protocol names (such as "UDP") to protocol numbers (like 17). This relates to what we might call "infrastructure" protocols, not application-level protocols.
networks	Maps network names to IP addresses.

I'm using the word "map" here for want of anything better. (It's the term used by NIS, one of the possible lookup services.) You might prefer the term "database," provided you don't think of a full-blown relational database. Or you might prefer the term "service," provided you don't think of a network service like HTTP or FTP.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 7: Network Services

Inhaltsvorschau

In the previous chapter, I discussed what I called the "infrastructure" of a Linux server. This chapter continues the server theme by discussing some key network services in detail. In the first lab, I'll show how to set up disk quotas to limit the disk space an individual can use. Later labs show how to provide DHCP and DNS services—in many ways the "glue" of the Internet. You'll also learn how to provide file sharing services using both the native Unix protocol (NFS) and the native Windows protocol (SMB/CIFS). I'll describe how to share out printers, using CUPS (Common Unix Print System). The final labs show how to set up your own web servers to host multiple sites on a single machine, and how to build a mail server.

Keep in mind that all of these services are available out of the box in a SUSE Linux distribution. In my view, it is the range and quality of these open source network solutions that really establish Linux's credentials as a world-class operating system.

Question: what does this command do?


$ cp /dev/zero foo

Answer: it will fill up all the free space on whatever partition your home directory is on. Linux does not, by default, limit the amount of disk space that a single user can use. If /home is on its own partition, a single user can starve all other users of disk space. If /home is not on a separate partition, a single user can probably bring the system to its knees by filling up the root partition.

However, Linux supports a disk quota mechanism, which limits both the number of files and the number of disk blocks that a given user (or group) can use. Separate limits can be applied to each partition, although typically only the partition carrying the user's home directory have quotas applied. The mechanism allows for both a soft limit, which can be exceeded for a specified grace period (a day, perhaps), and a hard limit, which can never be exceeded. In this lab, you'll see how to manage the quota system.

For this lab, I used YaST to create a 100 MB partition /dev/hda6 with a Reiser filesystem, mounted on /home2. I also created a user called robin, whose home directory is

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Set Up Disk Quotas

Inhaltsvorschau

Question: what does this command do?


$ cp /dev/zero foo

For this lab, I used YaST to create a 100 MB partition /dev/hda6 with a Reiser filesystem, mounted on /home2. I also created a user called robin, whose home directory is /home2/robin.

Without quotas, robin can fill the entire partition:


$ cp /dev/zero foo

cp: writing 'foo': No space left on device

$ df -h /home2

Filesystem            Size  Used Avail Use% Mounted on

/dev/hda6             102M  102M     0 100% /home2

$ rm foo

To enable quotas, edit /etc/fstab and add the mount option usrquota for the partition hda6, so that the line looks like this:


/dev/hda6    /home2       reiserfs   acl,user_xattr,usrquota    1 2

Now remount the partition so that the new mount option kicks in:


# mount -o remount /home2

Next, initialize the quota system on the partition. You need to do this only once:


# quotacheck -u /home2

Next, you must turn on the quota mechanism:


# quotaon -u /home2

Note that you must turn on the quota mechanism every time the system is booted. The best way to do this is to add the command:


quotaon -u -a

to the script /etc/init.d/rc.local. This script is run at boot time, after the filesystems are mounted but before run-level processing is started. The

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure a DNS Server

Inhaltsvorschau

One of the most fundamental pieces of the infrastructure that makes the Internet work is name resolution —the process of converting a fully qualified domain name like www.oreilly.com to an IP address like 208.201.239.36. On small local networks, that task is sometimes fulfilled using NIS, or even by doing local lookups in /etc/hosts. But to cope with Internet-wide name resolution, you must use DNS (Domain Name Service). DNS is one of the best examples we have of a distributed system—the knowledge of the IP addresses of all the machines visible on the Internet is spread across many thousands of servers.

"DNS" refers to the architecture; this name is not specific to Linux or Unix or any particular implementation. "BIND" is the name of a very popular implementation of DNS from the Internet Services Consortium, which is universally used on Linux. BIND stands for Berkeley Internet Name Domain (depending on who you ask). Finally, named is the name of the actual daemon that is part of the BIND distribution. It's pronounced "name-dee." Do not pronounce it any other way—at least, not in earshot of an expert.

In this lab, you'll see how to configure a DNS server using BIND.

Although there is a YaST module for configuring BIND, which absolves you from the need to deal with the (rather picky) syntax of its configuration files, it will make no sense unless you understand a little about the DNS architecture. So here are the basics.

Within DNS, each machine is identified by a fully qualified domain name (FQDN), such as www.dcs.shef.ac.uk. This name identifies a machine within a hierarchical namespace.

DNS names are rather like absolute pathnames in the filesystem, in that they identify a point within a tree-structured naming hierarchy. The big difference is that path names are written "big endian," with the most significant component first, as in /home/chris/book/chapter7, whereas DNS names are written little-endian.

DNS is a distributed system, and any one DNS server contains information only about machines in a part of the DNS namespace called a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Share Files Using NFS

Inhaltsvorschau

NFS, the Network File System, is a file-sharing technology pioneered by Sun Microsystems. It has been widely implemented for many years across many versions of Unix and Linux and can rightly be considered the "native" file-sharing protocol for Linux. This lab explains how to export filesystems from an NFS server and how to mount exported filesystems into the filesystem of a client.

To configure an NFS server, you must first define one or more exports. An export simply means a piece of the server's filesystem that it is willing to make available to clients. You must make sure that the relevant daemons are running. For reasons that I discuss later, there are three daemons: nfsd, mountd, and the portmapper. And of course, you must ensure that access to these daemons is not blocked by your firewall.

You can configure the server using YaST. From YaST's main screen, select Network Services from the panel on the left, then NFS Server from the panel on the right. On the first screen you can choose whether to run the NFS server, and whether to open up the relevant ports in the firewall. To enable NFS, select both of these options and proceed to the next screen.

This is where the real configuration happens. Here, you can add one or more directories that you want to export. (Click on Add Directory.) For each directory you add, you supply the full pathname of the directory (for example, /home). You must also supply an access control entry, which consists of a client specifier (YaST calls this field "Host Wild Card") and a set of export options. I will get into the details of these in a moment; as a simple example, setting the client specifier to * and the options to ro makes the export available read-only to all clients. As you add more directories in this way, the list of exported directories appears in the upper panel.

Each exported directory can have more than one access control entry. If you select a directory from the upper panel, its access control entries are shown in the lower panel. To add a new access control entry, click on Add Host. A typical screen is shown in Figure 7-3.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Serve Filesystems to Windows with Samba

Inhaltsvorschau

Linux systems rarely live on Linux-only networks. Most of them find themselves within existing infrastructures that contain large numbers of Windows machines. The Samba suite of programs allows a Linux system to integrate with Windows networks by providing file, print, and authentication services to Windows clients using the native Windows file-sharing protocols. Other components of Samba allow Linux to act as a client, accessing file and print resources on Windows servers. Using Samba as a server provides an easy, cost-effective, and relatively low-risk way for Linux to "get a foot in the corporate door," so to speak. As such, Samba is strategically an important suite of programs.

In this lab, you'll see how to serve filesystems to Windows clients, and how to authenticate users. Keep in mind that Samba is a large topic that has given rise to some fairly thick books all by itself. As a result, the treatment in this lab is necessarily brief.

First, make sure you have the relevant packages installed. You need kdebase3-samba, libsmbclient, samba, samba-client, samba-doc, samba-vscan, yast2-samba-client, and yast2-samba-server.

Most services can be configured in two ways (one using YaST and one using the command line), but in the case of Samba there are actually three, because there's also a browser-based graphical configuration tool called SWAT, which comes as part of the Samba suite. SWAT is my preferred tool and is the one I'll cover here. SWAT is started via xinetd and must be enabled. Edit the file /etc/xinetd.d/swat and change the line:


disable  =  yes

to read:


disable  =  no

Then tell xinetd to reread the file:


# rcxinetd restart

Now enter the URL http://localhost:901 into your browser. You'll be prompted to log in—enter root and your root password. (Be warned that if you choose to configure Samba from a browser on a remote machine, this login will pass root's password over the network in plain text.) You should see the SWAT home page shown in Figure 7-7.

Figure 7-7: SWAT home page

From this screen you can access the online documentation, which is extensive. Note that there seems to be a disagreement between where SWAT expects the online documentation to live and where it is actually installed. This is easily fixed with a well-placed symbolic link:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure a DHCP Server

Inhaltsvorschau

DHCP servers provide network configuration parameters to machines when they boot (or to be more accurate, when they start their network interfaces). DHCP stands for Dynamic Host Configuration Protocol. Most users think of DHCP as providing IP addresses for its clients to use, but it is able to supply many other pieces of configuration information, including the subnet mask, the broadcast address, the IP address of the default gateway, the IP address of one or more DNS servers, time servers, print servers, and so on. It can even supply a domain name for the client. This information (in particular the IP address) is not assigned to a client in perpetuity, but is leased to it for a specified time, which will typically be a few hours or days. The client can request a lease time when it makes the DHCP request. The server is configured with a maximum lease time (which will override the client if it asks for too long a lease) and a default lease time (which will be used if the client doesn't request a specific duration). Clients are expected to request renewal of their leases if they wish to keep using their assigned IP address, or to stop using the IP address if they allow the lease to expire.

DHCP offers a number of conveniences. First, it allows large-scale deployment of desktop systems by allowing each system to be imaged with an identical configuration. There is no need to go around and "tweak" each system to set its IP address and other settings. Second, it allows those of us who regularly move our laptops between networks to automatically pick up appropriate settings for that network, without tedious manual reconfiguration. Third, it allows reuse of IP addresses through the reclamation and reissue of expired leases.

You can configure a simple DHCP server with YaST. Select Network Services from the pane on the left of the main YaST screen, then choose DHCP Server from the pane on the right. The DHCP configuration module provides four screens on which you can specify settings as follows:

Start-Up screen: Specify whether dhcpd (the DHCP server) will be started at boot time, and start and stop it manually. (The first time you run this YaST module, the start-up screen appears last in the sequence.)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure a Web Server with Apache

Inhaltsvorschau

The Apache web server is one of the flagship successes of the open source community. According to recent Netcraft (http://www.netcraft.com) surveys, Apache is running about 70% of the world's active web sites. In this lab, you'll see how to set up a simple site.

Hosting a web site with Apache on SUSE Linux involves four steps:

Install the relevant RPMs

If you did a default installation of SUSE Linux, Apache is probably not installed. In the YaST software management module, select the Selections filter, then check the box labeled Simple Web Server with Apache 2. This should install all necessary packages.

Create a configuration for the server

The server configuration files are the main focus of this lab.

Put some content (.html files and so on) into the Server Root directory

Actual content generation (HTML, CSS, and so forth) needs a whole book to itself. We'll content ourselves with some very simple pages, just to prove that it's working.

Start the server

To arrange for the server to start at boot time, use the YaST runlevel editor (see Lab 6.1, "Control Boot-Time Service Startup") or enter the command:


# chkconfig apache2 on

To start and stop the server manually (for testing perhaps), use:


# rcapache2 start

# rcapache2 stop

Apache comes preconfigured and works out of the box, so even if you only do the first and last steps listed, you should be able to point your browser at http://localhost and see the placeholder home page that comes with the Apache distribution. On that page is a link to the documentation (also included as part of the distribution), which is very complete and very good.

Once the novelty of seeing the default home page has worn off, you will want to start providing your own content. The default configuration of apache sets a document root directory of /var/www/htdocs. The document root is the top-level directory of the filesystem that corresponds to this site's contents. For example, entering the URL

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure a Mail Server

Inhaltsvorschau

I sometimes wonder why folks pay good money for software to build a mail server when they can do a perfectly good job using free, open source applications. I'll show you how to do that in this lab.

Before I get down and dirty with the details of configuring a mail server, I'll take a look at the big picture of how mail is delivered. Figure 7-13 shows the overall architecture.

Figure 7-13: Mail system architecture

A mail user agent (MUA) is the program that an end user interacts with in order to compose or read email. Behind the scenes, the two roles of an MUA (sending and receiving) are largely separate. The MUA integrates the two by providing a unified system of folders for storing the messages it has received and the messages it has sent. It also provides ways for users to reply to or forward mail messages. There are many mail user agents. On SUSE Linux, KMail and Evolution are popular choices, but there is also the stalwart command-line tool simply called mail, which is useful if you need to send email from within a script. An MUA needs to be configured to tell it how to send outbound mail, and how to retrieve inbound mail. I discussed this in Lab 1.3, "Get Started with Email." Generally, the MUA hands off outbound messages to a mail transfer agent (MTA) for delivery.

The MTA is the piece of the system responsible for the "long haul" of email delivery. Mail is sent and received using a protocol called SMTP—Simple Mail Transfer Protocol. This is a text-based protocol and it's quite easy to conduct an SMTP conversation "by hand" using telnet. At first sight, pushing email around sounds like a pretty simple job, but it turns out to be surprisingly complex—determining whether the recipient is local or remote, queuing mail that can't be delivered immediately, bouncing messages that can't be delivered at all, filtering spam, and so on. The preferred MTA in SUSE Linux is postfix. This is the one we'll use in the lab, but there are others, including Exim, QMail, and the venerable but incomprehensible sendmail.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 8: Security

Inhaltsvorschau

This chapter is about keeping your system secure. It is, I think, a terrible indictment of human nature that such a chapter should be necessary at all. If people didn't try to attack computer systems, there would be no need to defend them. Sadly, we need to take security seriously.

Securing your system is a kind of risk management strategy, and there is usually a trade-off between security and convenience of use. You might try to quantify the cost of a security breach of your system like this:


Expected cost = (probability of an attack's success) * (cost of that attack)

Reducing the probability of an attack's success is generally known as hardening the system. A lot of this is common sense—educate users to choose strong passwords, disable or delete services you don't need, tighten up permissions on files as far as possible, establish a firewall, keep abreast of newly discovered vulnerabilities and keep software up to date, don't give out the root password, and so on. Reducing your cost of an attack is equally important. For example, detecting intrusion quickly is much better than allowing a breach to go unnoticed for days. Maintaining regular backups will limit any potential loss of data. Splitting your services across multiple machines (also known as not putting all your eggs into one basket) can help prevent a single breach from bringing your entire organization down.

The chapter is about defense rather than attack. You'll see how to thwart some of the more obvious ways of gaining root access to your machine by setting a grub password. You'll discover how to use the secure shell to access systems remotely without the risk of your activities and passwords being intercepted on the network. You'll learn how to set up a firewall and tighten file access permissions. You'll see how to break out from the all-or-nothing super-user model in Linux by implementing role-based access control. You'll meet vulnerability assessment tools that can help find insecurities and filesystem integrity tools that can help detect intrusion. The lab on AppArmor is of particular interest. It represents a novel way to profile the "normal" behavior of an application and prevent it from operating outside of that profile.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Set a Boot-Time Password

Inhaltsvorschau

Most SUSE Linux systems use grub as their boot loader. grub offers a lot of flexibility, including the option to intercept the boot process and edit the commands used to boot the system (or even to type new commands in from scratch). One particularly interesting trick is to append the parameter init=/bin/sh to the end of the kernel command used to load the Linux kernel. This tells the kernel to run a shell instead of the usual init program, and gives you root access to the filesystem without requiring the root password. There are obvious security implications here.

In this lab, you'll see how to password-protect grub to disable its interactive options unless a password is entered. Note that the password is not required to boot the system using the predefined entries in the grub config file, but only to edit them or enter other interactive commands.

Intercepting grub's boot process requires physical access to the machine, and there are other ways an unauthorized user can get at the machine's filesystem if he or she has physical access. For example, the intruder can boot from rescue media, or—if all else fails—physically remove the hard drive and take it somewhere else.

Setting a grub password is easy. Just hand-edit the grub config file (by default, it's /boot/grub/menu.lst) and add a line to the global settings near the top of the file that looks something like this:


password --md5 $1$H06141$PTIpTGW7fNKspluqd1Mdk.

The long string beginning with a $ is the md5-encrypted password. To generate this, run grub from a shell command prompt (this will take you to grub's interactive prompt) and enter the command md5crypt. You be asked to enter the desired password, and then it will display the encrypted version. The procedure looks like this:


# grub

    GNU GRUB  version 0.95  (640K lower / 3072K upper memory)



 [ Minimal BASH-like line editing is supported.  For the first word, TAB

   lists possible command completions.  Anywhere else TAB lists the possible

   completions of a device/filename. ]



grub> md5crypt



Password:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Provide Secure Remote Login with SSH

Inhaltsvorschau

In those days the stakes were high, men were real men, women were real women and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri. Spirits were brave, men boldly logged in to remote computers to which no man had remotely logged in before.

(With apologies to Douglas Adams)

—

Although they didn't realize it at the time, this was a daring, dangerous thing to do. They used a remote login service called telnet, which required them to supply a user name and a password to the server, both of which were passed over the network in clear text—that is, without encryption. Moreover, once they were logged in, their entire command-line dialog was carried over the network in clear text. FTP (File Transfer Protocol), another of the early work-horses of the Internet, suffered from similar problems. It remains popular to this day, though mainly in the form of anonymous ftp, in which no password is required and the files being transferred are publicly accessible anyway, so the lack of encryption is less of an issue. Of course, those were gentler times. Many of those early networks were local area networks with no direct connection to the Internet, and a (relatively) trustworthy user community. Even the people with access to the Internet were nice people and wouldn't dream of stealing passwords or eavesdropping on our digital conversations.

As an academic, for years I used to do a telnet login to my desktop machine at the university to read my email if I was working away from home. It never occurred to me that it might be insecure, and I never had the slightest problem with it. Spam was a brand of tinned ham, nothing more.

Nowadays, as a trainer, I sometimes set up in-class demonstrations in which I invite an attendee to perform a telnet login to my machine using a secretly supplied user name and password. I run an Ethereal (http://www.ethereal.com) packet capture session and show how to pull the login credentials "off the wire." Many attendees already understand the reality of how easy this is, but there are still some who are genuinely shocked by the ease of sniffing passwords from the network in this way.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Set Up a Firewall

Inhaltsvorschau

Down in the bowels of the Linux kernel lurks a piece of code known as netfilter. The netfilter code performs filtering of IP packets. It examines every packet that flows into, out of, or through the machine and decides the fate of the packet based on things such as the source and destination IP addresses, the source and destination port numbers, the flags present in the TCP header, and other stuff besides. The two basic actions that netfilter can perform on a packet are to accept it or to discard it. It can also log packet traffic via the syslogd service. Using netfilter, it is possible to set up a Linux system as a packet-filtering firewall. The traditional role of a firewall is as a machine that stands between an internal company network and the big bad Internet, protecting the former from the latter. In this case, filtering is applied to packets being forwarded between the machine's inward-facing network interface(s) and its outward-facing interface. It is also possible to filter packets flowing into or out of the firewall itself, allowing netfilter to be used to construct a sort of "personal firewall" that is useful even in the simplest case of a single home machine connected via an ADSL line or dial-up connection to the Internet.

Indeed, the Internet has become a sufficiently threatening environment that you would be well advised never to connect a machine to it directly without a personal firewall in place.

Netfilter is configured by a number of filtering rulesets. From the command line, rules are managed using the iptables command. The syntax of iptables represents a complete packet-filtering "language" in its own right. A typical rule includes components that identify which packets the rule matches, and ends with a statement of whether to accept or drop packets that match the rule. To give the merest hint of how it looks, here's an example:


iptables -A INPUT -i eth0 -p udp \

         -s $NAMESERVER --sport 53 \

         -d 140.116.5.1 --dport 53 -J ACCEPT

It is possible, in theory, to build a complete firewall ruleset by hand-crafting a series of iptables

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Define a Security Level

Inhaltsvorschau

An initial default installation of Linux will inevitably establish a certain level of security, as defined by the overall file permissions, the range of enabled network services, the firewall rules, and so on. Early distributions of Unix and Linux were relatively open in their settings "out of the box," with practically every available network service enabled by default. Over the years, default installations have become more closed and secure, requiring the user to explicitly open the system up and enable just those services they want to run. However, there is no "one size fits all" answer to the question of what the default security settings should be. Settings that would work fine for an isolated, single-user home machine would certainly not be appropriate for a so-called bastion host on a company's DMZ network. With this in mind, SUSE Linux includes a sort of security wizard that allows you to specify a number of security related settings that, overall, define the security level of the system.

To run the security wizard, start YaST. From the main YaST screen, select Security and Users from the panel on the left, followed by Local Security from the panel on the right. From the screen titled "Local Security Configuration," you can select one of three predefined sets of security settings, in order of increasing security:

Home workstation
Networked workstation
Network server

If you wish, you can simply select one of these levels, click Finish, and be done with it. This might feel like a rather dumb way of configuring your system's security, but it's a lot better than doing nothing at all. To configure your security in more detail, select Custom Settings and click on Next. (Though you really need to sit down and write down a security policy first.) This will take you to the first of five screens on which you can specify a variety of security settings:

Password Settings: On this screen you can enable or disable password strength checking. This is a check applied at the time that a user chooses a new password that helps ensure that the password cannot be easily guessed by a program like

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Provide Role-Based Access Control with sudo

Inhaltsvorschau

The security model in Linux goes back a long way—to the early days of Unix, in fact, round about 1969. To set this into context, that was the year that man first landed on the moon, Woodstock happened, and the Foundations had a hit with "Build Me Up Buttercup." However, the original IBM PC wouldn't be invented for another 12 years. If you're too young to know what I'm talking about, what I mean is that "it was a long time ago...."

Surprisingly, the security model hasn't evolved much since then. We still have read, write, and execute permissions on files for user, group, and others. There have been a few additions, such as POSIX capabilities, "immutable" files, and access control lists (not much used in my experience), and recently we've seen the introduction of SELinux (Security Enhanced Linux) from the National Security Agency in the United States, which brings mandatory access controls to Linux at the expense of rather complex configuration. But the basic model remains.

One of the things most obviously missing from Linux is the lack of a role-based access control model (such as is found in Solaris, for example). The idea of role-based access control (RBAC) is that you can define roles such as "Printer Administrator" or "Network Administrator" and define privileges for these roles. For example, a printer administrator might be allowed to purge all jobs from the print queues, a network administrator might be allowed to change a machine's IP address, and a user manager might be able to add user accounts. Then you assign roles to users. So, Joe might have the roles "Network Administrator" and "User Manager" and Mary might have the role "Printer Administrator."

Under the basic Linux model, there is really only one special role—the super-user—which is associated with the root login. As you know, this is a rather all-or-nothing approach to granting privilege, as the super-user can do anything.

The subject of this lab is a utility called sudo, which allows something approximating a role-based access control model on Linux. sudo allows specified (nonroot) users to execute specified commands as root, under control of a configuration file.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Assess Vulnerabilities Using Nessus

Inhaltsvorschau

Okay, so you've taken all the usual advice about creating a secure system. You've enabled only the services you actually need. You're running SuSeFirewall2. You've downloaded all the security-related updates from YaST Online Update. You've tightened down the file permissions as far as you can. Can you be sure that your system is secure? Well, it will certainly be more secure than if you hadn't done those things, but to answer the question with more confidence, consider running a security assessment tool. In this lab, you'll see how to use Nessus, a network vulnerability scanner included in the SUSE Linux distribution, to remotely scan the systems on your network for potential security problems.

First, make sure you have the packages nessus-core, libnasl and nessus-libraries installed. (I am disappointed to note that these packages are not on the SUSE Linux 10.1 beta CDs from the OpenSUSE site; however, you should be able to download them from ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-10.0-OSS/inst-source/suse/i586.) Nessus has a client and server component. The server, called nessusd, is the piece that performs the actual tests, and the client, nessus, is a graphical application that allows you to log in to the server, specify the tests you want to perform, and view the test results. For the client to connect to the server, the server must present a known SSL certificate to the client, and the client must present a valid username and password to the server. So, on the machine on which you plan to run the server, there are a couple of things you need to do. First you need to create a Nessus user account. These are used only to control login to the Nessus server and aren't related to regular Linux accounts. The account creation tool, nessus-adduser, is quite chatty and the dialog is fairly self-explanatory. Here's an example:


# nessus-adduser

Using /var/tmp as a temporary file holder



Add a new nessusd user

----------------------



Login : joe

Authentication (pass/cert) [pass] :

Login password :

Login password (again) :



User rules

----------

nessusd has a rules system which allows you to restrict the hosts

that joe has the right to test. For instance, you may want

him to be able to scan his own host only.



Please see the nessus-adduser(8) man page for the rules syntax



Enter the rules for this user, and hit ctrl-D once you are done :

(the user can have an empty rules set)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Detect Intrusion

Inhaltsvorschau

There are a number of tools available for Linux that can help alert you to unwanted intrusion into your system by detecting unexpected changes to the filesystem. Such tools support a reactive, as opposed to proactive, attitude to security and should not be considered a substitute for the system hardening techniques discussed elsewhere in this chapter. The idiom "closing the stable door after the horse has bolted" comes to mind here. Nonetheless, if your system has been hacked, it is much better to know than to not know. The idiom "hiding your head in the sand" also comes to mind here, and I suppose that if you were a horse-owning ostrich you could do both. But I digress.

In this lab, I'll look at an intrusion detection tool called AIDE (Advanced Intrusion Detection Environment), which is included with the SUSE Linux distribution. AIDE works by first taking an initial "snapshot" of the state of the filesystem. Subsequently, AIDE can be run to compare the current filesystem status against the snapshot, and report any discrepancies.

Assuming that AIDE is already installed on your system (it is part of the SUSE Linux distribution; use rpm -q aide to check, and install it using YaST if it is not), you should begin by taking an initial snapshot of the filesystem. To do this, log in as root and run the command


# aide --init

You should do this at a time when you are confident that the system is in an uncompromised state (for example, after installing it from trusted media and performing the initial configuration, but before connecting it to a network). Because this command scans the entire filesystem it will likely take several minutes to complete.

By default, the snapshot is written to /var/lib/aide/aide.db.new. This is a plain text file. A "snapshot" of the filesystem is not a complete binary copy, but a summary of file attributes and file contents designed to allow detection of changes. A snapshot of a file includes its name, access permissions, user and group ownership, size, time of last modification, time of last status change, inode number, link count, and one or more

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Protect Your Applications with AppArmor

Inhaltsvorschau

AppArmor is a product that Novell acquired when they bought the company Immunix in May 2005. It provides an interesting alternative to traditional security measures. AppArmor works by profiling the applications that it is protecting. A profile records the files that an application needs to access, and the capabilities it needs to exercise, during normal, "good" operation. Subsequently, a profile can be "enforced"; that is, attempts by the application to access resources not explicitly permitted by the profile are denied. Properly configured, AppArmor ensures that each profiled application is allowed to do what it is supposed to do, and nothing else.

The documentation uses the metaphor of "immunizing" the applications, but the product does not actually prevent an application from being infected or compromised. Rather, it limits the damage that an application can do if this should happen.

If we must have a medical metaphor, "quarantine" might be better, or you might think of it as offering the program a large white handkerchief to sneeze into to prevent it from spreading germs.

AppArmor was originally a closed-source product, but became open source in January 2006. It is included with SUSE Linux 10.1 and with SLES9 SP3. It was also included with SUSE Linux 10.0, but the profiling tool was deliberately restricted in scope and required the purchase of a license file to become fully functional.

To give you a feel for how AppArmor works, in this lab I'll use it to profile and contain a very simple C program. Whilst this example is undeniably simplistic, it does help to show how AppArmor actually works.

Here's the program that you will profile. It's called scribble, because it scribbles on files:


#include <stdio.h>



int main(int argc, char *argv[])

{

    int i;

    FILE *fd;

    for (i=1; i<argc; i++) {

        fd = fopen(argv[i], "w");

        if (fd == NULL) {

            fprintf(stderr, "fopen failed for %s\n", argv[i]);

            return 1;

        }

        fprintf(fd, "scribbled on file %s\n", argv[i]);

        fclose(fd);

    }

}

If you can't read C, don't worry, it doesn't really matter. The program loops over its command-line arguments, treating each as a filename. For each one, it tries to open the file for writing, writes a line of text to it, then closes the file. If it can't open the file, it prints an error message. I created the source file

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Chapter 9: Alternative Installations

Inhaltsvorschau

In Chapter 1, I discussed how to install SUSE Linux in some detail. At one end of the scale, you can do the job with almost no thought whatsoever by booting off the installation DVD and repeatedly clicking Next until you end up with a working system. At the other end of the scale, there are a number of more complex scenarios you may need to deal with, and it is these that I discuss in this chapter.

You'll see how to configure a dual-boot system to retain the option of booting into Windows. You'll learn how to set up an installation server to facilitate installation over the network instead of from local disk media. You'll discover how to automate installations entirely by preparing a control file that captures the decisions that you would normally make manually during an installation. Finally, I'll show you how to use Xen (a "paravirtualization" technology) to install and run multiple operating systems—simultaneously—on one machine.

Some of us Linux enthusiasts would like to imagine that users migrating to a Linux desktop actually throw their Windows installations away, with looks of rapture like someone newly converted to The Faith turning away from their erstwhile sinful existence. In reality, few of us can leave our Windows systems behind completely. You probably still need some applications that run only on Windows—that program your friend gave you for doing your VAT returns, and the cross-stitch design program your wife uses, not to mention that flight simulator you're rather partial to. There are several ways that you can retain the ability to run Windows applications after migrating to Linux. In some cases, you can install and run the apps over Linux using Crossover Office (a product based on the wine library). Or, you may decide to install Windows inside a VMware virtual machine hosted on Linux. (This is actually my preferred solution, but it needs plenty of memory and doesn't support graphics-intensive applications such as games.) But the most common solution is probably to create a dual-boot installation in which Windows and Linux exist side-by-side on the hard drive, each in its own partition, so that you can choose which to boot when you power on.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Configure a Dual-Boot System

Inhaltsvorschau

In this lab, you'll see how to create a typical dual-boot system using Windows XP and SUSE Linux.

The most important piece of advice I have is: put the Windows installation on first. The Linux installer will recognize existing Windows partitions and take them into account. It will automatically put an entry into the grub configuration file to allow you the option of booting into Windows, and it will put entries into /etc/fstab so that the Windows partitions are automatically mounted into the Linux filesystem at boot time. Doing it the other way around is more problematic.

There are two scenarios to consider. The first is when you're starting from scratch installing both operating systems onto an empty machine. When you do the install of Windows XP, you should explicitly set the size of the partition it will install into. Its default behavior is to use all the free space on the drive. It's up to you to determine how best to split the disk space between Windows and Linux. Another point to consider is that Linux supports read/write access to FAT filesystems, but only read access to NTFS filesystems. If you are intending to share your main user file area between Windows and Linux, you may prefer to specify a FAT filesystem.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Install from an Installation Server

Inhaltsvorschau

If you have many machines to install, and if they're all on your network, you may find it convenient to configure a machine as an installation server and pull the installation from the server, rather than using local DVDs or CDs. This is especially helpful for machines that have no DVD drive (or won't boot from DVD) because it saves shuffling the CDs around during the installation. Once you have initiated an installation, you can walk away from it. This lab first examines how to configure the installation server, then shows how to launch a network installation.

You can set up an installation server on any machine able to support NFS, FTP, or HTTP—it doesn't have to be a Linux machine. But as this book's interest lies in SUSE Linux, I use that as the basis of the installation server.

You can configure an installation server using YaST. To do this, you'll need to have the package yast2-instserver installed. You can check this using:


$ rpm -q yast2-instserver

If it isn't installed, install it now using YaST → Software → Software Management (Lab 5.3, "Install and Upgrade RPMs" in Chapter 5 shows how to do this). Once the package is installed, quit and restart YaST, then go to YaST → Miscellaneous → Installation Server.

At the Installation Server screen, click Server Configuration. As you will see from the "Initial Setup—Servers" screen, you can build your server to use NFS, FTP, or HTTP. Whichever you choose, YaST will try to configure the relevant service to make the installation images available (unless you check the box labeled "Do not configure any network services"). Also on this screen, specify the directory where you want to put the CD images. This is entirely up to you—but choose a directory on a partition with plenty of free space. In this lab, I configure the server as an HTTP source and put the CD images into the directory /installroot.

On the next screen, provide the name of an alias that will be used by the HTTP server to reference the installation root directory. This name will form part of the URL that you'll specify when you launch the installation on the target machine. In this lab, I use the name

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Automate Installations with AutoYaST

Inhaltsvorschau

Working manually through the SUSE Linux installation screens once (or even twice) is quite interesting; perhaps even enjoyable. Doing it 200 times is tedious. AutoYaST enables you to prepare the answers that the installer asks you ahead of time and put them into a control file. This saves a huge amount of time if you're installing many machines. If all the machines are the same, it's very easy. If the machines are broadly similar, then it's still quite easy. Even if there are quite drastic differences between the machines, it's still possible to prepare a control file so that different machines get different configurations. AutoYaST is SUSE's answer to RedHat's Kickstart; indeed, it is even possible to import a Kickstart file into YaST as a starting point. AutoYaST works well in combination with installing from a network server to provide an almost completely "hands-off" installation process.

First, make sure you have the packages autoyast2, autoyast2-utils, and autoyast2-installation installed.

AutoYaST needs two things—a network installation server (see Lab 9.2, "Install from an Installation Server") and a control file. It's also possible to do an AutoYaST installation from CDs or DVD, but because the whole point is to minimize the amount of manual intervention, I'll not consider that case.

The control file can be created in several ways; it's an XML file and can be created manually (preferably using an XML editor such as KXML Editor), but the easiest way is to use YaST, which will create a control file based on your currently installed system. From the YaST main screen, select Miscellaneous from the panel on the left, then Autoinstallation from the panel on the right. From the Tools menu of the next screen, select Create Reference Profile. On the next screen, you can select which components (beyond the default) of the configuration of this machine will be copied into the control file. See Figure 9-3.

Figure 9-3: Creating an AutoYaST control file with YaST

Typically, you would select the following:

Firewall
Network Services (xinetd)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Run Multiple Operating Systems with Xen

Inhaltsvorschau

Virtualization is a hot topic, despite the lack of any well-articulated explanation of what it actually means. At risk of contradiction, let's attempt a definition:

Virtualization is a software technique that provides the illusion of a real machine environment but which in reality is layered on top of a (possibly quite different) hardware platform.

Some so-called virtualization products are properly called emulators, since they emulate one processor architecture on top of another. Microsoft's Virtual PC 7, for example, emulates an Intel processor on top of a Power PC, allowing you to run many x86 operating systems, including Microsoft Windows, Linux, BSD, and Solaris on a G3, G4, or G5 Mac. Such techniques, which must emulate one processor's instruction set on another, are usually slow.

Additionally, virtualization and emulation products are designed to support multiple virtual machines concurrently, allowing several (possibly different) operating systems to execute on the same hardware at the same time. These operating systems are called guests of the virtual machine environment, which runs on top of the host operating system.

True virtualization products create a controlled environment under which applications run directly on the host CPU. Linux running in Virtual PC on a PowerPC Mac thinks it is running on a Pentium II class CPU, because that is what Virtual PC emulates. Linux running in VMware (perhaps the best known virtualization product) on an Athlon 64 is in fact running directly on that Athlon 64, but under controlled conditions. (Virtual PC for Windows uses true CPU virtualization as well.)

This lab looks at an open source virtualization package called Xen and shows how you can create virtual machines (Xen calls them domains) and boot Linux inside them. Unlike VMware, Xen is a hypervisor; it runs directly on the bare hardware, not on top of a host operating system. When you boot a system that has been Xen-enabled, the Xen hypervisor is started up alongside your primary operating system.

You will need to install the packages bridge-utils, libreiserfs

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Zurück zu SUSE Linux

Inhaltsverzeichnis

Section 1.3.1.1: Kmail

Section 3.7.1.1: To rip an audio CD

Section 3.8.1.1: To create a data CD

Themen

Buchreihen

Special Interest

International Sites