Working with SUSE Linux Enterprise Server 9

Date: Jun 17, 2005

Sample Chapter is provided courtesy of Sams.

Return to the article

Instant Access

Working with SUSE Linux Enterprise Server (SLES) requires an understanding of the login process, including local account files, system accounts, and managing identities.

Using a console shell or the graphical environment are two possible methods of working on a SLES machine.

Finding your way around a SLES installation requires an in-depth knowledge of the filesystem layout. Essential filesystem components are documented and explained in this chapter. Basic filesystem permissions are also described.

The SLES help system includes the use of both man and info pages.

Editing text files from a console session is normally done with the vi editor. Modes of vi are explained and tables of common commands used with vi are provided.

Although a complete guide to using SUSE Linux Enterprise Server (SLES) is beyond the scope of this book, an understanding of Linux and basic Linux functionality is necessary for successful deployment of OES Linux.

This chapter will discuss essential Linux concepts, such as understanding the login process, using the command-line and graphical environments, finding your way around the filesystem, using the available help systems, and understanding text-editing tools. Linux-proficient administrators may want to skip to Chapter 6, "SUSE Linux Enterprise Server Management," for more in-depth SLES information, but breezing through this chapter for an introduction to SUSE-specific utilities and environments might be helpful. If you are new to Linux, this chapter should get you started, but this is not intended to be a comprehensive or beginner’s Linux guide.

If you’d like a more thorough investigation into Linux fundamentals or SLES administration, Novell Education’s Certified Linux Professional (CLP) and Certified Linux Engineer (CLE) programs are well worth looking into. For more information on Novell’s SUSE Linux certification options, see Appendix A, "CLE Certification Options."

Logging in to Linux

After installing and booting a SLES server, you should be presented with either a text or graphical login prompt. Entering an appropriate username and password will give you access to the server. For an administrator, it is important to understand how access is granted and how local SLES user accounts are configured. It is also important to have this knowledge prior to implementing OES components such as Linux User Management (LUM). The following section will briefly discuss local user accounts and how the local authentication process works.

Local Account Files

On a SLES9 server, local user accounts are defined in the /etc/passwd file as shown in Figure 3.1. Every user defined in this file must have certain attributes that are used by the server for determining such things as user permissions and login name. The format of /etc/passwd is one user account entry per line.

Each line within the passwd file is made up of five fields, separated by colons. These fields provide the necessary attributes for user accounts to be considered valid by the operating system. The purpose of each field is documented in Table 3.1 for the entry jdoe:x:1000:100:John Doe:/home/jdoe:/bin/bash.

Figure 3.1 An example of the /etc/passwd file.

Table 3.1 Explanation of /etc/passwd Entry

If the second field in the /etc/passwd file is an "x", shadow passwords are enabled. This is the default configuration for SLES. Shadow passwords provide for a more secure environment, and allow for additional password aging options.

When you use shadow passwords, an additional configuration file is used for storing encrypted user passwords. This file is the /etc/shadow file. Table 3.2 explains the fields of this file for the entry jdoe:AztgeYU5TrGn.:12702:0:38:7:3:::.

Table 3.2 Explanation of /etc/shadow Entry

Within the /etc/passwd file, the fourth field contains the GID of the primary group of the specified user. When users create files and directories, the new filesystem objects receive a user owner and a group owner. The user owner is the UID of the user who created the filesystem entry. The group owner is the GID of the user’s primary group at the time of object creation. (Both the UID and GID numbers are converted to user and group names when viewing file listings.) Local groups are defined in the /etc/group file. Table 3.3 shows the fields and their definitions for the entry users:x:100:tjohnson,mblack.

Table 3.3 Explanation of the /etc/group File

Creating and modifying local user accounts and groups can be done with several utilities. Within SLES, the YaST utility can be used to easily create these accounts. (Information on YaST can be found in Chapter 6.) Users and groups can also be added to the system using several command-line utilities. A few of these utilities are listed in Table 3.4.

Table 3.4 Local User and Group Utilities

The Root Administrator Account

Within Linux, the superuser or administrator account is known as root. This account has all rights over everything found on a Linux server. It is important to realize that these rights cannot be locked out or restricted in any way. Given the vast amount of power root has, a secure and confidential password must be used for this account.

It is also important to avoid using the root account just for the sake of accessibility. When you are logged in as root, malicious scripts or programs can potentially be deadly to your Linux environment if they are run accidentally. Be sure to avoid these issues by logging in as a regular user and only using root privileges when necessary. (See the "Switching Identities" section later in this chapter for more information on that topic.)

The UID for root is always 0 (zero). This is hard-coded into many aspects of Linux and should not be manually adjusted. Also, when integrating local Linux accounts into OES through LUM, the root account should not be included. Local user account access to the server as the root user is critical for many troubleshooting steps.

The Login Process

There are actually many methods by which a user can authenticate or log in to a Linux server. The tables in the preceding section describe how local user accounts are stored in the system, but having a local user account is only one step in the login process.

Local logins are not the only method of authentication to a Linux server. Logins can be initiated through several methods, including remote graphical sessions, remote shell sessions, and service-specific type of authentications, such as occur when authenticating to a Samba server.

Although these types of authentications normally rely on the local user account files, most can also be configured to authenticate using a remote user account store. These stores can be many different types, but authentication back to an LDAP-enabled directory, such as eDirectory, is an extremely common method of providing account management. OES provides for this functionality in the Linux User Management (LUM) component. LUM is covered in detail in Chapter 8, "Users and Network Security." LUM is actually quite complex, and understanding the authentication process of a local login should help you get prepared for implementing LUM.

In SLES, Pluggable-Authentication Modules (PAM) are used to provide user authentication to all PAM-enabled services. PAM-enabled services include local logins, secure shell access, and most other services requiring authentication. PAM configuration of these services is performed using service-specific configuration files found in /etc/pam.d. In this directory, each service relying on PAM to enforce authentication has a configuration file. The default login configuration file used for local logins is shown in Figure 3.2.

PAM configuration divides the authentication process across four distinct module types. The explanations for these module types can be found in Table 3.5.

Figure 3.2 Contents of /etc/pam.d/login.

Table 3.5 PAM Module Types

Each module type takes one of four control flags as a parameter used to indicate how that specific module is to be handled. These control flags are explained in Table 3.6.

Table 3.6 PAM Control Flags

The last two fields of the PAM configuration file for any service are used to denote external authentication modules and any parameters those modules may require. Many different modules can be used for each portion of the authentication stages. These modules range from providing LDAP lookup for user accounts to checking passwords for certain security requirements.

In the case of a login process based on the configuration file in Figure 3.2, the authentication process would have to successfully pass all requirements for each specified module in order to generate a fully authenticated connection. In other words, the pam_unix2.so module would ensure that the user’s account exists and is allowed access. The pam_securetty.so module then determines if the user is allowed to log in from the current terminal. The pam_nologin.so module is used to check for the existence of an /etc/nologin file, which would prevent non-root users from logging in. This process continues until all modules have been processed. If the PAM modules are successfully processed, the user is authenticated and provided with a shell prompt. Otherwise, the user is denied access.

Switching Identities

When you have logged in to a Linux environment using your local account, you may find that you have insufficient privileges to accomplish a specific task. In order to execute certain commands, or have rights to view specific files, it is sometimes required to change your identity to that of the root user. To do this, you must use the su command.

The su or "substitute user" command is used to temporarily substitute your identity with that of another user. When run as a normal user and executed with no parameters, the su command will prompt for root’s password. After the password has been entered, the current session will be given root-level access. (To return to your normal permissions, use exit.) The su command can also be used to switch to the identity of another, non-root user. To perform this action, specify the desired user name as a parameter to su, as shown in Figure 3.3.

Figure 3.3 An example of using the su command.

It is important to realize that the su command does not otherwise modify the current environment. In other words, executing su will not change the current directory, or the currently configured environment variables. When switching to another user’s identity, it is often desirable to also assume that user’s environment. This requires switching identities and also executing a normal login process for the new user. In order to temporarily switch users and complete a login cycle as that user, the su command must be executed using a "-"command-line parameter, as shown in Figure 3.4.

Figure 3.4 Example of the su - command.

The Shell and the GUI

You can interact with SLES by using one of two methods. The first method is the use of a shell or console, and the second method is a Graphical User Interface (GUI). This section will explain and discuss both environments and provide tips for using these two components of SLES.

The Shell

The heart of the SLES operating system is the Linux kernel. The kernel’s primary responsibility is to manage running processes and their interaction with the various hardware components of a computer. This includes management of memory (RAM), processors (CPU), hard disks, and other hardware components. Left on its own the kernel manages these components quite well. However, without the guidance of a user or administrator, the kernel certainly will not accomplish much!

For an administrator, the ability to interact with the Linux kernel can be more important than the kernel itself. One important way to facilitate interaction with the kernel is through the use of a "shell."

A shell is a program designed to accept user input, validate that input based on certain criteria (such as syntax and permissions), and then pass instructions off to the kernel for processing. This shell functionality is very similar to the familiar DOS shells under Microsoft Windows environments. Linux shells, however, are much more powerful than traditional non-Unix shells and therefore can be more complex and difficult to master.

One reason for this complexity is the fact that several shells are available for use in Linux environments. Although the purpose of these shells is essentially the same across all variations, the implementations can differ dramatically. These differences are typically manifest in syntax and feature-set capabilities, but each shell can also be substantially different from a usability perspective as well.

Table 3.7 Common Linux Shells

Each shell has its own specific features and advantages. If you already use one of these shells, or some other shell, feel free to continue to use that shell. If you are new to the Linux environment, the BASH shell is usually the default shell and is an excellent shell for new users. Throughout this book, all shell command syntax will be issued with BASH in mind, although other shells nearly always understand this syntax as well. The remainder of this section will introduce you to concepts and features of the BASH shell.

Invoking the Shell

Although invoking the shell may seem like a rather straightforward topic, there are a few important aspects of this topic that should be pointed out.

If no graphical environment was installed with SLES, after server startup a login prompt should be presented. Simply logging in as a valid user will invoke that user’s default shell. This behavior will also be encountered if the graphical environment is installed, but not configured for automatic startup. In either case, following the login prompts will lead you to a shell environment.

From within a graphical environment on Linux, there are a number of terminal programs that will invoke a shell. Common graphical shells are listed in Table 3.8.

Table 3.8 Common Graphical Terminal Programs

Launching a graphical shell is a simple task of locating the corresponding shell icon and clicking on it, or entering the application command name in a "run command" type of dialog. This will typically start the shell using the credentials of the currently logged-in user. A commonly found graphical shell is the KDE-based Konsole, which is shown in Figure 3.5.

In addition to graphical terminals, another method used to gain shell access is using the "Virtual Terminals" available in Linux environments.

Virtual Terminals are terminal sessions bound to a specialized device on Linux. Rather than being attached to a physical hardware device, such as the connection of a serial cable to a COM port, connections to Virtual Terminals are accomplished through bindings represented by the keyboard function keys. Typically, the first six function keys (F1–F6) are bound to full-screen terminal sessions using the mingetty program. Function key F7 is normally bound to the first graphical environment running on the Linux computer. It is also possible to have a second graphical environment running and bound to the F8 function key.

Figure 3.5 Konsole terminal utility.

You can access these Virtual Terminals by pressing a combination of control keys. In graphical environments such as KDE, this keystroke combination is Ctrl+Alt+Fn (where Fn is substituted for the desired terminal). When you have accessed a Virtual Terminal, you must enter valid user credentials prior to invoking a usable shell.

Another common way of invoking a command shell is through remote shell access via another computer. The basic method of invoking this access is through a telnet session. Telnet connections can be made from nearly every operating environment to a Linux server. However, telnet uses an insecure protocol and therefore telnet connections are not normally allowed to Linux servers. By default, SLES does not allow telnet connections. To alleviate security risks inherent with telnet, a Secure SHell (SSH) session can be used for encrypted remote access.

Secure shell support on Linux servers is provided by the OpenSSH software program. On SLES, OpenSSH is configured by default and is the recommended method of remote access. Connecting to the OpenSSH server is possible from other Linux machines using the ssh program. Basic usage of ssh is as follows:

#ssh johndoe@192.168.1.56

After issuing the ssh command, the user is prompted for a password for the SSH session. Upon successfully entering the password, the default shell of the designated user is invoked.

The only potential drawback to SSH is the fact that SSH client programs are not commonly available on non-Linux workstations. Table 3.9 lists a few commonly used programs that provide SSH client support in Windows environments.

Table 3.9 SSH Clients for Windows

Given the benefits of SSH remote shells, using one of these or other secure shell clients on non-Linux workstations is well worth the investment.

Using the Shell

After you’ve invoked a shell, you can perform any number of actions. Command execution is the primary reason for invoking a shell, and for that execution to be successful, there are a few rules you need to be aware of:

• External commands (standalone programs, not built-in shell functions or aliases) can only be executed if they are found within directories specified by your PATH environment variable. All other external commands can only be executed if the command is referenced using a valid path to the program.

NOTE

The current directory is not normally in your path. To execute a script or program found in the current directory, it is typically necessary to invoke the command using the full path as follows:

./script

The "./" indicates the current directory.

• The permissions on a file determine whether or not that file is executable. Most standalone applications and utilities should already have a correct set of rights assigned to them. However, if you are working with shell scripts, be sure to assign the execute (x) flag to the script prior to attempting to execute the script.

• Linux shells are case sensitive. This means that all filenames, commands, and command parameters are case sensitive. Often, command-line parameters differ dramatically based on the case used. Be sure to double-check all parameters before executing critical commands!

• Know the difference between relative and absolute paths. Many commands in Linux reference source or destination directories and files. When using these commands, it is critical that you distinguish between a relative and an absolute path.

• Any path or filename reference beginning with a slash (/) is referring to the absolute path to that file—from the root of the drive. Relative path and filenames typically start with no path or with a single period followed by a slash (./) indicating the current directory. The parent directory can be referenced using a double period followed by a slash (../).

• If relative and absolute paths are used incorrectly, files can be inadvertently written to locations off the root of the drive, rather than the intended location.

Before you begin following these rules, there are a number of shell features you should know about that make working in a Linux shell a much more effective practice. A few important features are explained in this list:

• Tab completion—Tab completion allows users to press the Tab key while working at a shell prompt and have BASH attempt to autocomplete the filename or path. If a beep is heard, multiple matches have been found. Pressing Tab a second time will display all matching items.

• History—The BASH shell automatically tracks commands entered by each user. These commands can be accessed by pressing the Up and Down arrow keys. The history command can also be used to display the entire known history of the current user.

You can then issue commands stored in your history using an exclamation point (!) followed by the history number entry, or an exclamation point followed by the first few characters of the desired command. When using the first few characters of a command, the most recent entry that matches those characters is executed.

• File globbing—File globbing is the process of the shell interpreting wildcard characters rather than the utility being called. When a command-line utility is executed, the shell itself searches and satisfies any wildcard characters and then executes the command using the matching parameters. For example, if the command ls /etc/is* was executed, the BASH shell would actually determine all matches for /etc/is* and actually execute ls /etc/issue /etc/issue.net.

File globbing can be beneficial if used properly and quite harmful if used incorrectly. If you would like to prevent file globbing, be sure to escape any wildcard characters by using a backslash or by enclosing the parameter containing the wildcard in quotation marks.

• I/O redirection—Linux uses built-in file descriptors to denote the standard input, standard output, and standard error channels. These descriptors are numbered 0, 1, and 2 respectively. Redirecting input or output to and from a command can be done using the > and < metacharacters.

The less-than (<) metacharacter is used exclusively for redirecting input into a command from a file. The greater-than (>) metacharacter is used for redirecting either or both standard output and standard error channels to a file. To execute a command anstandard output and standard error to a file, the following syntax is used:

ls /etc/* > etc.dir

When redirecting both standard output to the same file, the following syntax is used:

cat /etc/passwd /etc/passwd.bad > ok.txt 2> err.txt

To write both standard error andd log the output into a text file, the following syntax would be used:

cat /etc/passwd /etc/passwd.bad > ok.txt 2>&1

Warning

When you redirect output using the ">" metacharacter, output will be written to the specified destination file whether or not the file exists. Existing files will be overwritten. To append data to existing files rather than overwriting those files, use double greater-than signs (>>).

• Command chaining—Command chaining allows the standard output of one command to be redirected into the standard input channel of a second command. To perform this function, the two commands are separated on the same command line using the pipe (|) metacharacter. The following example shows the output of the cat command being redirected and used as input for the sort command:

Command chaining can be used to chain a virtually unlimited number of commands together. The BASH shell processes these commands one at a time. After completing each command, the output of that command is then passed as input to the next command.

With the preceding framework of required rules and shell tips, you are now ready to interact with files, run commands, and navigate the filesystem. Unfortunately, providing a list of all BASH commands you might need would require another complete book! However, some essential command-line tools are described in the "Finding Your Way" section of this chapter. A more complete list of the most essential commands used in Linux has also been compiled in Appendix B, "The Most Essential Linux Commands."

The SLES Graphical Environment

The SLES graphical environment is similar to most Linux-based workstations, such as the Novell Linux Desktop (NLD). These graphical environments tend to be rather complex and a complete understanding of each graphical component is necessary to thoroughly troubleshoot any issues that might arise. The following section provides an overview of these components.

XFree86

To provide a graphical environment, SLES uses the XFree86 implementation of the X Window System. This same graphical, or X, server is used on Linux workstations and is not always installed in server environments, but SLES, by default, does install the graphical environment.

Your server may be configured to automatically start the graphical environment and provide for a graphical login, or it may start and prompt for a text-based login. To reduce operating overhead in a server environment, many configurations provide for text-based logins, but do allow the graphical environment on demand. To start the graphical server from a text-based login, execute the startx command after logging in.

A complete graphical environment on SLES consists of several layers of graphical components. These components and a brief description of them can be found in Table 3.10.

Table 3.10 Components of the SLES Graphical Environment

Each component of the X Window System plays an important role in the overall goal of providing users with a complete graphical environment. Although some components are optional, all components rely on the base X server for graphical functionality by interacting with the video card and monitor.

The X server configuration is performed using the sax2 utility. This utility is automatically launched during the SLES installation if a graphical environment is selected for installation. After installation, sax2 can be run from either the command line or the graphical environment to adjust graphical settings. Additional hardware configuration changes, such as selecting an appropriate mouse, can be performed from within the Hardware section of YaST.

Desktop Environments

When installing SLES, you have the option of installing a KDE, GNOME, or minimal graphical environment. The minimal graphical environment is a bare-bones environment designed to provide an X server for graphical applications. On the other hand, KDE and GNOME are both desktop environments and offer a full graphical environment complete with taskbars, application launchers, unified menus, screensavers, and many other components common to workstation environments.

K Desktop Environment (KDE)

The K Desktop Environment (KDE) is the default desktop for SLES 9. A typical desktop view is shown in Figure 3.6. KDE is based on the Qt graphical toolkit and therefore most applications used under KDE are also based on this toolkit. As long as required libraries are available, applications based on other graphical toolkits can still run under a KDE environment (such as running GNOME apps under KDE).

Figure 3.6 The K Desktop Environment (KDE) workspace.

KDE offers a complete desktop environment that includes the following components:

• The Desktop—The desktop consists of the background and one or more icons used to access common programs or utilities. Launching applications from the desktop is done using a single mouse click on the appropriate icon.

• The KDE Control Panel or Kicker—The Kicker is known as a taskbar in other graphical environments. In KDE, the Kicker is used to provide immediate access to commonly used programs, a task manager for running programs, virtual desktops, and environment-specific applets (such as the clock). You can configure the Kicker by right-clicking on the main panel and selecting Configure Panel.

• The KDE menu—The KDE menu is accessed using the green button with a red "N" on the left side of the Kicker. The KDE menu provides easy access to graphical programs installed on the local server. Right-clicking on the KDE menu provides a link to a tool for menu editing. This tool can be used to adjust or add icons to the menu easily.

• Virtual Desktops—KDE includes support for up to 16 virtual desktops. By default, only two virtual desktops are configured. You can access each desktop by using the center section of the Kicker panel. To configure the virtual desktop, right-click on the desktop and choose Configure Desktop, Multiple Desktops.

Central to KDE is the Konqueror utility. Konqueror is an integrated file manager and web browser. In addition to performing those two tasks, Konqueror also offers extensive features such as accessing information through several different network protocols, interacting with local hardware devices, and providing the KDE help system.

Konqueror is the default web browser with KDE, but Mozilla and Firefox can both be installed as part of the SLES installation, and used in place of Konqueror. OES officially supports both the Mozilla and Konqueror browsers.

GNOME

During the SLES installation, the GNOME desktop can be installed either in addition to KDE or as a replacement for KDE. GNOME is based on the GTK+ graphical toolkit. As with KDE, as long as the required graphical libraries are available, all graphical applications can be used under GNOME. Figure 3.7 shows a GNOME desktop with common GNOME-based utilities.

GNOME offers a complete desktop environment that consists of the following components:

• The Desktop—The desktop consists of the background and one or more icons used to access common programs or utilities. Unlike KDE, launching applications from the GNOME desktop is done using a double mouse click on the appropriate icon.

• The Top Panel—The Top Panel is used to provide easy access to available applications. This panel is fully configurable and can be customized with additional links to applications. By default, this panel includes links to the Nautilus file manager, a terminal emulation window, and applets for the clock and volume control.

• The Bottom Panel—The Bottom Panel is used to provide access to currently running programs through a task manager interface in the middle of this panel. The Bottom Panel also displays an icon for closing all open windows and revealing the desktop. Accessing virtual workspaces is also accomplished using this panel.

• The Applications Menu—The Applications menu is accessed using the Top Panel. This menu contains links for currently installed graphical applications.

• Virtual Workspaces—GNOME includes support for up to 36 virtual workspaces (called virtual desktops in KDE). By default, only 4 virtual workspaces are configured. You can access each workspace by using the right section of the Bottom Panel. Right-click on the Virtual Workspaces applet to configure the virtual workspace.

Figure 3.7 The GNOME Desktop workspace.

GNOME utilizes Nautilus as the main tool for file management and Epiphany as the default web browser. The Epiphany web browser is also supported for OES web-based utilities. As in KDE environments, both Mozilla and Firefox can be installed and used in place of Epiphany.

FVWM

In addition to the two desktop environments of KDE and GNOME, the SLES installation also allows for the installation of a minimal graphical environment. This environment is based on the Feeble Virtual Windows Manager (FVWM) window maker (fvwm2). As shown in Figure 3.8, this Desktop Environment certainly offers fewer features than KDE and GNOME.

Figure 3.8 The FVWM Desktop workspace.

FVWM is a powerful, yet minimalist window environment. Rather than employing large, memory-consuming menus and advanced window features, FVWM focuses on providing an efficient and powerful graphical environment. Due to this focus, new users may find FVWM a difficult environment to master. Other users appreciate the low-resource footprint when using FVWM—particularly in a server environment.

Features of FVWM include the following:

• The Desktop—The desktop of FVWM consists of just a background graphic. Unlike KDE and GNOME, there are no desktop icons in FVWM. Clicking on the desktop with the left mouse button will invoke the "Work Menu" pop-up. Clicking the right mouse button will invoke the "KDE Menu" pop-up.

• FvwmButtons—FvwmButtons create a group of buttons on the root desktop screen. The grouping of buttons includes such things as a clock, and links to SUSE and FVWM utilities. Links to shells and other utilities can also be found in the button grouping.

• KDE Menu—Accessed by clicking the right mouse button on the desktop, the KDE menu contains links to applications configured in the KDE environment. Applications visible in this menu are determined by what is installed on the server.

• Work Menu—Accessed by clicking the left mouse button on the desktop, the Work menu provides a menu containing links to commonly used applications such as the Pine editor, Mozilla browser, and other configuration utilities.

Credentials and the X Server

When you’re logged into the graphical environment as a normal user, a common operation is to open a terminal and launch graphical X client applications directly from the shell prompt. If your shell credentials are the same as your credentials in the graphical environment, these commands can be executed without issue. However, if you switch identities to that of the root user (or any other user), access to the X server will be denied, and you will be unable to launch graphical programs.

When starting the X server, your credentials are provided to the X server. For security purposes, SLES configures X to only allow access to the local X server from trusted sources. By default, this is only the logged-in user. To allow graphical access while switching users, SLES provides the sux utility.

The sux utility automatically configures the new user’s environment to support access to the local X server. The sux utility replaces the functionality of the su utility, which is used to switch identities within normal shells. The syntax of sux is identical to that of su.

Tunneling X

In addition to providing graphical access to switched identities, it is also possible to redirect the display of graphical clients running on the SLES server to a remote X server running on the local workstation. This is useful when you want to run a graphical program on the SLES server, but do not want to start the X server. Running programs in this manner is best accomplished by forwarding the X connection through an SSH tunnel.

SSH tunnels can be established to the SLES server from a Linux workstation using the ssh command. Through the use of the -X startup option, X11 forwarding can be enabled via that same SSH tunnel. When you are connected in this manner, you can launch graphical programs on the SLES server and display them using the local X server.

Remote Graphical Sessions

Using Virtual Network Computing (VNC), a graphical desktop session can be started on the local server while physically using a Linux, Windows, or Apple MacOS-based workstation. During the SLES 9 installation, remote administration through VNC can be set to "enabled." Otherwise, remote administration will be disabled and must be enabled using the YaST – Network Services – Remote Administration module.

When remote administration has been enabled, VNC connections can be made to the server using one of three methods:

• VNC client-based connections—Using a VNC client, a connection using the VNC protocol can be made to the server on port 5901. VNC clients include krdc for Linux, and RealVNC for Windows (http://www.realvnc.com). VNC clients are also available for several other platforms.

• VNC connection in Konqueror—Using a Linux workstation, the Konqueror browser can be used to provide a VNC connection to the SLES 9 server. This connection is a true VNC connection and connects to the same port (5901) that the standalone VNC client would connect to. The full URL for this type of connection within Konqueror is vnc://<serverDNSorIP>:5901.

• Brower-based connections—Using a Java-capable web browser, an HTTP connection to the server on port 5801 (<serverDNSorIP>:5801) will invoke the Java-based VNC client.

Although remote administration through VNC is convenient, the VNC protocol is not as secure as a full secure shell (SSH) session. For this reason, establishing a full SLES login through VNC is not recommended outside of secure LAN environments.

Finding Your Way

Now that you are familiar with the graphical and console working environments in SLES, you might still find yourself somewhat lost within the environment itself. This section provides an introduction to the filesystem layout and offers an insight into filesystem permissions and potential navigation pitfalls.

System Filesystem

During the system startup process, the Linux kernel loads modules required to access the hard disks into memory. With these modules, physical connections to the hard disk partitions can be established.

Under Microsoft Windows and other operating systems, the filesystem is accessed through drive letters assigned to each individual partition. Linux, on the other hand, provides access to all partitions through a single, virtual directory structure. Accessing separate partitions is a matter of navigating to the correct directory.

The process of associating a partition to a directory within the filesystem is known as "mounting." During system initialization, the partition containing the core operating-system files is mounted to the root (/) of the directory tree. This partition is known as the system or "root" partition.

After root has been successfully mounted, remaining partitions are then mounted to specific directories within the root directory structure. The /etc/fstab file is used as a configuration file, which determines where each partition will be mounted. Directories used for mounting filesystems are known as "mount points."

Table 3.11 lists the main directories found after a SLES installation and briefly describes their purposes.

Table 3.11 Root Filesystem Components

Upon opening a shell terminal, you are normally presented with a command prompt while residing within your user’s home directory. This can be confirmed by using the Print Working Directory (pwd) command, as shown in Figure 3.9.

Figure 3.9 Displaying the current path using pwd.

Navigation through the filesystem is similar to other operating systems. There are a few shortcuts you should be aware of. Table 3.12 describes these useful shortcuts and provides examples for using them.

Table 3.12 Navigation Shortcuts

 # cp /etc/passwd .

# cd .. 
# cd ../sibling_directory

# ./test_script

 # cd ~ 

 # cp /etc/passwd ~jdoe/passwd.old

 # cd -

In addition to knowing the shortcuts, knowing basic navigation tools is also important to successfully navigate the filesystem. Although Table 3.13 is not a comprehensive list of commands, it identifies the major navigation-related commands used in Linux.

Table 3.13 Basic Navigation Commands

Filesystem Permissions

With knowledge of the filesystem layout and the commands required to navigate that filesystem, there is only one thing that could possibly stop you—permissions.

Permissions on files and directories in Linux can be viewed using a long file listing (ls –l). The output of this command will look similar to Figure 3.10.

Figure 3.10 Output of ls –l.

Long file listings display the permissions on a file or directory on the far left side of each entry. This field is known as the "mode" of the file and consists of ten specific bits. The first bit is used to indicate the type of file being viewed. Possible file type values are listed in Table 3.14.

Table 3.14 Possible File Types

The remaining nine bits represent the permissions on the specified file, as shown in Figure 3.11. These bits are logically divided into three groups of three bits each. The first set of three bits represents the permissions that the owner of the file has. (The owner is displayed as the third field in a long directory listing with ls.)

Figure 3.11 Layout of file mode.

The second set of three bits represents the permissions assigned to the group owner of the specified file. (The group owner is displayed as the fourth field in a long directory listing with ls.) All members of the specified group receive the designated rights to the file.

The final set of three bits represents permissions that all other users receive to the specified file.

Each of these sets of three bits all represent the same set of three rights—read, write, and execute. These permissions behave differently based on whether they are set on a file or a directory. Table 3.15 describes the difference in these permissions.

Table 3.15 Permission Differences Between Files and Directories

Setting Permissions and Ownership

The chown utility can be used to change the owner and group owner of files and directories. When using chown, specify the new user and group owners followed by the file or directory. The user and group names are separated with a period. Here’s an example of this:

chown jdoe.users /tmp/tmpfile

In order to change permissions on a file or directory, you must use the chmod utility. The chmod utility can be used to change permissions using two different methods. The first method is through using a symbolic representation of permission assignments. This requires identifying which set of permissions you are changing; what permissions you are assigning; and an operator that determines whether rights are being added or subtracted. Table 3.16 lists possible values for these three fields.

Table 3.16 Common Symbolic Parameters for chmod

Using the symbolic method, multiple permissions can be set by separating each setting with a comma. The following example demonstrates this:

chown u+a,o+r /tmp/tmpfile

The second method of changing permissions with chmod is through using an octal number representation of the desired permissions. This is routinely seen and important to understand.

In an octal interpretation of permissions, each right is assigned a number. The read permission is assigned a value of 4, write is assigned a value of 2, and execute is assigned a value of 1. These numeric assignments are used for all three sets of permissions as shown in Figure 3.12.

Figure 3.12 Octal representation of file mode.

To assign permissions using the octal method, add up the value of each set permission bit in each category (user, group, and other). Each category will range from 0 to 7. After each category has been calculated, use chmod as follows:

chmod 750 /tmp/testfs.sh

In the preceding example, all permissions (rwx) are assigned to the user category, read and execute (r-x) are assigned to the group, and no permissions (---) are assigned to the other category.

Special Permissions

In addition to the normal permissions, there are three special permissions that you might encounter. These permissions are as follows:

• Set User ID (SUID)—The SUID bit is used on executables to modify the permissions allowed to the running process. When an executable with the SUID bit is executed, the running process inherits the permissions of the owner of the executable—rather than the permissions of the user who launched the program. This is useful when a running process should have more rights than a normal user is typically provided.

• Set Group ID (SGID)—The SGID bit performs two functions. The first is similar to the SUID bit. An executable with the SGID bit set inherits the permissions of the group owner when running—rather than the group permissions of the user who started the process.

The second function the SGID bit performs is only valid on directories. With the SGID bit set on a directory, all newly created files within that directory automatically receive the same group owner as the group owner of the directory. This overrides the default assignment of each file receiving a group owner set to the individual user’s primary group.

• Sticky Bit—The Sticky Bit is only valid on directories. When the Sticky Bit is set on a directory, users are only allowed to delete files that they own. Without this setting, users are allowed to delete files owned by other users as long as they have the write (w) permission on the directory.

Special permissions are stored as part of the regular mode of the file, but there is no room for three more permission bits for these permissions. Because of this, special permissions are actually included within the execute (x) bit of user, group, and other permissions. Figures 3.13 and 3.14 demonstrate how these permissions are displayed when the corresponding execute bit is set and not set, respectively.

Figure 3.13 Special permissions that appear when the execute bit is set.

Figure 3.14 Special permissions that appear when the execute bit is not set.

Even though special permissions are displayed as part of the normal mode of the file, setting special permissions is done through the use of one more permissions category with the octal mode of chmod. With this category, SUID is assigned a value of 4, SGID a value of 2, and the Sticky Bit a value of 1. You can set these permissions as follows:

chmod 3775 /data/sales

Getting Help

SUSE Linux provides literally thousands of possible commands that can be used to perform various tasks on a server. Having firsthand knowledge of each utility and all parameters that utility may take is a very challenging task! Thankfully, through the use of utility manuals and application documentation, help is never too far away.

Console-Based Help

Working on the command line is the most common method of interacting with SLES. Providing easy access to application and utility usage information from this environment is essential to effectively working on the command line. Thankfully, a help system has been designed around just this need. This system consists of three distinct types of documentation: manual or man pages; info pages; and system and third-party documentation.

man Pages

man pages on Linux are syntax-level documentation of utilities and applications, stored in an easily retrievable, command-line-friendly format. man pages are physically stored in the /usr/share/man directory and divided into the nine sections shown in Table 3.17.

Table 3.17 man Page Sections

All programs utilizing the man system should store their man pages within the correct section. In order to view man pages for a specific command, the following basic syntax must be used:

man [section] command

Upon entering the man command, you are presented with syntax-level documentation for the specified command or utility. The pages presented typically contain information divided into the following sections:

• Name—This is a one-line summary of the application in question. This field is displayed individually when using the whatis command.

• Synopsis—This section contains a summary of the command line for the application in question. Optional parameters are enclosed in square brackets [], and required parameters are listed normally.

• Description—This section documents the possible parameters the application in question can receive. Some man pages also include specific usage examples in this section.

• Author—The author’s name and contact information are typically noted in this section.

• Reporting Bugs—Information on where to report bugs for the specific utility is normally noted in this section.

• Copyright—The utility’s copyright information is normally displayed in this section.

• See Also—This section identifies additional locations for information on the utility in question. Quite often this section will identify related utilities, man pages, and info pages for the specific utility. Checking all specified resources is recommended for advanced usage techniques including troubleshooting of the utility.

Most man pages are only a few pages in length, but some man pages can be quite detailed with many, many pages of information. (See man bash for one such example!) Navigation through larger man pages can be greatly simplified with details on a few valid keystrokes. Table 3.18 lists a small number of important navigation commands within man.

Table 3.18 Internal man Keystrokes

It is also common to want to search through man pages for a specific type of utility. Although searching through the contents of all man pages is possible, it is more likely that you just need to locate a command that performs a specific action. Searching just the "Name" section of all man pages is the best way to accomplish this. The apropos or man -k commands can be used for this purpose. For example, to find all commands related to cron, you would use the following command:

The output of this man command would be a listing of all commands containing the word "cron" anywhere in the Name field. After the utility has been identified, the man page for the desired command can then be directly accessed for more information.

info Pages

In addition to the man system, information regarding programs and commands can also be found using the info system. Due to the syntax-documentation-only focus of man pages, background information, tutorials, and detailed information on using the program in question are sometimes lacking in man pages. The info system was created to directly resolve that issue.

info pages are detailed usage instructions and program or command guides. This documentation is accessed via an emacs-type interface that supports hypertext links, and advanced navigation features not found in the man system. The following command is an example of using the info system to locate documentation on the Concurrent Versions System (CVS):

Within the info system, multiple individual pages of information make up the entire set of info pages for each specific application. These pages of information are referred to as nodes. You can page through nodes one at a time, or you can jump to specific pages through the use of hypertext links. For new users, this navigation can be challenging.

To help node navigation, info pages all display a header across the top of the page. This header includes information such as the current node, next and previous nodes, and information regarding the parent node. Although this helps to visualize your location in the info system, you still need to know basic navigation commands before you’ll feel entirely at home. Table 3.19 describes some of these important navigation keys.

Table 3.19 Internal info Keystrokes

System and Third-Party Documentation

The final common forms of documentation found on SLES are system- and application-specific documentation. This documentation can be in HTML, PDF, plain text, or many other formats. All application-specific documentation can be found in application-specific directories beneath /usr/share/doc/ packages. SLES-specific documentation, release notes, and a collection of HOWTO guides can also be found beneath specific directories in /usr/share/doc.

Graphical Help Systems

KDE and GNOME both have an integrated help system. This makes accessing help from a graphical environment a much simpler task than from the command line. The graphical help systems normally provide help for the graphical environments, but they also provide access to the existing man and info pages as well.

KDE Help

In KDE, the KDE Help Center is the interface into the SUSE help system. To access the SUSE help system, single-click on the "SUSE Help Center" icon (the image of a gecko in the middle of a life preserver) from the KDE Kicker. When you’re in the Help Center, SUSE documentation and application-specific documentation can easily be accessed.

Using KDE, info pages and man pages can also be easily viewed. To access these systems, launch Konqueror and enter a specific URL for man or info pages. The syntax for accessing man pages is man:<desired_pages>. For example, man:ls would be used to view the man pages for the ls command from within Konqueror. To access info pages, substitute info: for man:, for example, info:cvs to view the info pages for CVS.

GNOME Help

As with KDE, GNOME also provides a graphical help system. This help system is based on the yelp utility.

From within GNOME, the help system is accessed from the Applications program menu. Within this menu, click on the Help icon (life preserver) to launch yelp at the home page for GNOME help. If complete GNOME documentation is installed, links to GNOME-specific help will be displayed on the yelp home page. (SLES does not provide GNOME Desktop documentation.) Links to additional documentation (man and info pages) are also displayed on the yelp home page.

Editing Text Files

A chapter on working with SLES would not be complete without a discussion on one more important topic—editing text files. Although editing text files may not sound like a difficult subject, common tools used when editing text files under Linux tend to be rather cryptic. Devoting some space in this chapter to help clear up confusion in this area should make first-time administrators much more comfortable and effective with any task involving text editing.

The vi Utility

It is possible to use graphical text-editing tools under SLES. Many such tools are easily available in both the KDE and GNOME graphical environments. However, a reliance on graphical editors (such as Kate or Gedit) also produces a dependence on a graphical environment. This graphical environment is often not running on a SLES machine. Also, when using a remote shell for SLES administration, graphical tools require tunneling X over SSH. Rather than enabling this tunneling or always using a graphical session on the server, learning and using a command-line editor is more effective and a better solution for the long term.

As in the graphical environment, several command-line text editors are available. Among the choices for command-line editors are pico, emacs, and vi. Pico and emacs are both powerful text-editing utilities that offer several appealing qualities. However, these utilities are not always available on SLES installations. The vi utility is the only text-editing utility that is nearly guaranteed to be available with any Linux installation.

The vi utility is an extremely powerful text-editing utility. Unfortunately, the almost limitless capabilities of vi have also caused its usage to become fairly cryptic and challenging for new users. The most important vi concept to understand is that vi operates in a bimodal fashion. Bimodal means that when using vi, you can be in one of two possible modes—command mode or insert mode.

The command-mode environment is used for such tasks as performing file operations, copying and pasting text, performing global search-and-replace operations, and working with macros. The insert mode of vi is used for normal text-editing operations. Probably more important than the two modes themselves is the ability to determine what mode vi is currently in!

When vi is initially launched, the interface is left in command mode. It is important to understand that direct file editing is not possible in command mode. Text can be copied and pasted, and various actions such as deleting text can still be accomplished, but adding additional text to the file by typing is not possible. In order to add text to the document, you must first switch to insert mode.

Insert mode is entered by pressing "i" or one of a few other insert text keys. When you are in insert mode, the bottom of the vi window will display the text "— INSERT –". Prior to adding text to the file, be sure you are in the correct mode by looking at the bottom of the window for that text. When you’re in insert mode, you can switch back to command mode by pressing the ESC key. Table 3.20 lists some of the commands that can be used with insert mode.

Table 3.20 Commands Used to Enter Insert Mode

As previously mentioned, the command mode is used to perform file operations, global text operations, and several other possible actions. These operations are either entered via one of several keystroke combinations, or through a special ":" prompt within vi. A few of the possible commands issued via the : prompt are documented in Table 3.21.

Table 3.21 Common Prompt Commands Used in Command Mode

Table 3.22 Common Keystroke Combinations Used in Command Mode

These three tables of vi commands have just barely scratched the surface of what vi is capable of. Although it may seem challenging, the most effective way to learn vi is by using it. When you are proficient with the commands outlined here, enter :help from the command mode of vi for more usage information.

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240