Red Hat Fedora Linux 3 Bible

Fedora and Red Hat Linux systems have advanced enough in recent releases that you can now do most system administration from your desktop GUI, bypassing the shell altogether. Whether you administer Fedora from the GUI or from a shell, however, underlying your activities are many administrative commands, configuration files, and log files.

Becoming Super User in X

There may be times when an X GUI is running on Linux as a non-root user and you want to run a graphical administration program. In most cases, the GUI administration program will simply prompt you for the root password to continue. However, if the program fails, saying that you don't have permission to run the command, here is what you can do:

First, open a Terminal window on the X desktop.

Then, open permission to the X window display to everyone on the local computer (this is just a temporary measure) by typing:

$ xhost +localhost

Type the following and enter the root password when prompted, to become super user:

$ su - Password: ****** #

Next, type the following to see the current display value:

# echo $DISPLAY

If the value is something like :0 or :0.0, any X command you run from that shell will appear on the console terminal for the computer. If you are at the console and that’s what you see, then you can skip the next step. If you see no value (which is quite possible) or the wrong value, you must set the DISPLAY variable.

Type the following (assuming you are using a bash or sh shell):

# export DISPLAY=:0

At this point, you can run any administrative X command (such as neat or system-config-packages) and have it appear on your X desktop. If you are running an administrative command from a remote computer and you want it to appear on your local desktop, you can set the DISPLAY to host:0, where host is replaced by the name of your computer.

When you are done, be sure to exit the application you are running. Then restore the security of your X desktop by typing the following:

$ xhost –

Understanding where GUI tools, commands, and files are located and how they are used will help you effectively maintain your Fedora system. Although most administrative features are intended for the root user, other administrative users (described later in this section) have limited administrative capabilities.

Using graphical administration tools

The trend over the past few versions of Fedora and other Red Hat Linux distributions has been to steer clear of the massive administrative interfaces (such as linuxconf and Webmin) and instead to offer graphical windows that perform individual administrative tasks. Instead of sharing one monolithic interface, they share common menus. Individual graphical windows for configuring a network, adding users, or setting up printers can be launched from that menu.

Note 

In Fedora Core 1 and previous versions of Red Hat Linux, the GUI administrations tools all began with redhat-, such as redhat-config-network and redhat-logviewer. Starting with Fedora Core 2, those names have all changed to system-, resulting in names like system-config-network and system-logviewer.

To administer your Fedora system through the GNOME or KDE desktops, Red Hat, Inc. has provided a common menu (Red Hat calls it the Main Menu; I refer to it as the red hat menu). In GNOME click the red hat; in KDE, click the K icon in the lower-left corner of the desktop.

Because these administrative tasks require root permission, if you are logged in as a regular user you must enter the root password before the GUI application's window opens. For example, if you launch the System Logs window (System Tools ® System Logs) from the GNOME menu as a regular user, you see the pop-up window shown in Figure 10-1.

Figure 10-1: Enter the root password to open system administration windows from a regular user’s GUI.

After you have entered the root password, most of the system configuration tools will open without requiring you to retype the password during this login session. Look for a “keys” icon in the lower right corner of the panel, indicating that you have root authorization. Click the keys to open a pop-up window that lets you remove authorization. Otherwise, authorization goes away when you close the GUI window.

Note 

As you configure different features on your Fedora or Red Hat Linux system, you are asked to launch different individual graphical windows. In general, if you have a choice of tools for configuring a server or adding a feature, I recommend that you use the tool provided with your distribution. That’s because the Red Hat GUI tools more often integrate closely with the way Fedora and Red Hat systems store and manage their configuration information.

The following list describes many of the GUI-based windows you can use to administer your Fedora or Red Hat Linux system. Start these windows from the System Settings or System Tools submenus on your red hat menu:

Procedures for using the various system graphical administrative tools are discussed throughout the book.

Administrative commands

Many commands are intended only for root. When you log in as root, your $PATH variable is set to include some directories that contain commands for the root user. These include the following directories:

Some administrative commands are contained in regular user directories (such as /bin and /usr/bin). This is especially true of commands that have some options available to everyone. An example is the /bin/mount command, which anyone can use to list mounted file systems, but only root can use to mount file systems.

To find commands that are intended primarily for the system administrator, check out the section 8 manual pages (usually in /usr/share/man/man8). They contain descriptions and options for most Linux administrative commands.

Some third-party applications will add administrative commands to directories that are not in your PATH. For example, an application may put commands in /usr/local/bin, /opt/bin, or /usr/local/sbin. In those cases, you may want to add those directories to your PATH.

Administrative configuration files

Configuration files are another mainstay of Linux administration. Almost everything you set up for your particular computer — user accounts, network addresses, or GUI preferences — is stored in plain-text files. This has some advantages and some disadvantages.

The advantage of plain-text files is that it is easy to read and change them. Any text editor will do. On the downside, however, is that as you edit configuration files, no error checking is going on. You have to run the program that reads these files (such as a network daemon or the X desktop) to find out if you set up the files correctly. A comma or a quote in the wrong place can sometimes cause a whole interface to fail.

Throughout this book, I describe the configuration files you need to set up the different features that make up Fedora systems. In terms of a general perspective on configuration files, however, there are several locations in a Fedora file system where configuration files are stored. Here are some of the major locations:

Administrative log files

One of the things that Linux does well is keep track of itself. This is a good thing, when you consider how much can go wrong with a complex operating system. Sometimes you are trying to get a new facility to work and it fails without giving you the foggiest reason why. Other times you want to monitor your system to see if people are trying to access your computer illegally. In any of those cases, you can use log files to help track down the problem.

The main utilities for logging error and debugging messages for Linux are the syslogd and klogd daemons. General system logging is done by syslogd. Logging that is specific to kernel activity is done by klogd. Logging is done according to information in the /etc/syslog.conf file. Messages are typically directed to log files that are usually in the /var/log directory.

Fedora includes a System Logs window (System Tools ® System Logs) you can use to view and search system log files from the desktop. See Chapter 14 for a description of that window and of the log files you can view with it.

Using other administrative logins

You don’t hear much about other administrative logins (besides root) being used with Fedora. It was a fairly common practice in UNIX systems to have several different administrative logins that allowed administrative tasks to be split among several users. For example, a person sitting near a printer could have lp permissions to move print jobs to another printer if they knew a printer wasn’t working.

In any case, these administrative logins are available with Linux, so you may want to look into using them. At the very least, because individual software packages such as bind, squid, and amanda set up permissions for their log files and configuration files based on their administrative logins, maintaining those permissions can prevent someone who hacks into one of those services from gaining control of the whole computer.

Tip 

Because most Fedora administrative features are expected to be administered by the root user, e-mail for other administrative accounts is routed to the root user. If you want other administrative users to receive their own e-mail, delete the aliases for those users from the /etc/aliases file.

Understanding administrative logins

Here are some of the administrative logins that are configured automatically for Linux systems. By tradition, these logins are assigned UID numbers under 100. Here are examples:

Tip 

Most administrative logins have no passwords by default. They also typically have /sbin/nologin assigned as their shell, so if you try to log in as one of these users, you see a This account is currently not available message. That's why you can’t use an administrative login separately until you assign it a password and shell (such as /bin/bash).

Using sudo for assigning administrative privilege

One way to give full or limited root privileges to any non-root user is to set up the sudo facility. That simply entails adding the user to /etc/sudoers and defining what privilege you want that user to have. Then the user can run any command he or she is privileged to use by preceding that command with the sudo command.

The following is an example of how to use the sudo facility to cause any users that are added to the wheel group to have full root privileges:

  1. As the root user, edit the /etc/sudoers file by running the visudo command:

    # /usr/sbin/visudo

    By default, the file is opened in vi, unless your EDITOR variable happens to be set to some other editor acceptable to visudo (for example, export EDITOR=gedit) The reason for using visudo is that the command will lock the /etc/sudoers file and do some basic sanity-checking of the file to ensure it was edited correctly.

    Note 

    If you are stuck here, refer to the vi tutorial in Chapter 4 for information on using the vi editor.

  2. Uncomment the following line to allow users in the group named wheel to have full root privileges on the computer:

    %wheel ALL=(ALL) ALL

    The previous line causes the user to be prompted for a password to be allowed to use administrative commands. To allow users in the wheel group to have that privilege without using a password, uncomment the following line instead:

    %wheel ALL=(ALL) NOPASSWD: ALL

  3. Save the changes to the /etc/sudoers file (in vi, type ZZ).

  4. Still as root user, open the /etc/group file in any text editor and add the users you want to have root privilege to the wheel line. For example, if you were to add the users mary and jake to the wheel group, the line would appear as follows:

    wheel:x:10:root,mary,jake

At this point, the users mary and jake can run the sudo command to run commands, or parts of commands, that are normally restricted to the root user. The following is an example of a session by the user jake after he has been assigned sudo privileges:

[jake]$ sudo umount /mnt/win We trust you have received the usual lecture from the local System Administrator. It usually boils down to these two things: #1) Respect the privacy of others. #2) Think before you type. Password: ********* [jake]$ mount /mnt/win mount: only root can mount /dev/hda1 on /mnt/win [jake]$ sudo mount /mnt/win [jake]$

In the above session, the user jake runs the sudo command so he can unmount the /mnt/win file system (using the umount command). He is given a warning and asked to provide his password (this is jake's password, not the root password).

Notice that even after jake has given the password, he must still use the sudo command to run the command as root (the first mount fails, but the second succeeds). Notice that he was not prompted for a password for the second sudo. That’s because after entering his password successfully he can enter as many sudo commands as he wants for the next five minutes without having to enter it again. (You can change the timeout value from five minutes to however long you want by setting the passwd_timeout value in the /etc/sudoers file.)

The preceding example grants a simple all-or-nothing administrative privilege to everyone you put in the wheel group. However, the /etc/sudoers file gives you an incredible amount of flexibility in permitting individual users and groups to use individual applications or groups of applications. I recommend you refer to the sudoers and sudo man pages for information about how to tune your sudo facility.

Related

Категории