Working with SUSE Linux Enterprise Server 9

This chapter is from the book

Novell Open Enterprise Server Administrator's Handbook, SUSE LINUX Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Novell Open Enterprise Server Administrator's Handbook, SUSE LINUX Edition

Learn More Buy

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.