Certification Objective 1.07: System Administration

 < Day Day Up > 



Most system administration tasks require root or superuser privileges. You should already be familiar with a number of basic Linux system administration commands and files. Standard user files are stored in /etc/skel. Daemons are processes that run in the background and run various Linux services. cron is a special daemon that can run scripts when you want. It's especially useful for setting up backup jobs in the middle of the night. Logging is a key part of monitoring Linux and any services that you choose to run.

Superuser

Generally in Linux, a system administrator does everything possible as a normal user. It's a good practice to use superuser privileges only when absolutely necessary. But one time where it's appropriate is during the Red Hat exams. Good administrators will return to being normal users when they're done with their tasks. Mistakes as the root user can disable your Linux system.

There are two basic ways to make this work:

  • su The superuser command, su, prompts you for the root password before logging you in with root privileges. A variation, su -c, sets up root privileges for one specific command. Many Red Hat GUI utilities are set up to prompt for the root password before they can be started. One more variation, su - root, sets up root privileges with the root user PATH. (Remember to have a space on both sides of the dash in this command.)

  • sudo The sudo command allows users listed in /etc/sudoers to run administrative commands. You can configure /etc/sudoers to set limits on the root privileges given to a specific user.

However, Red Hat Enterprise Linux provides some features that make working as root somewhat safer. For example, logins using the ftp and telnet commands to remote computers are disabled by default.

Exam Watch 

On the RHCE and RHCT exams, time is of the essence. In general, I recommend that you don't bother logging in as a regular user during these exams. It's faster to log in as the root user. You don't have to remember to invoke the su or sudo commands, and you gain the advantages of a more liberal PATH variable. While you just save a few seconds with each command, that time can add up.

/etc/skel

Basic configuration files for individual users are available in the /etc/skel directory. This directory includes a number of hidden files. For a full list, run the ls -a /etc/skel command. If you want all future users to get specific files in their home directories, include them here.

The next time you create a regular user, check that person's home directory. For example, if you just created a user named elizabeth, run the ls -a /home/elizabeth command. Compare the results to the previous command on the /etc/skel directory.

Daemons

A daemon is a process that runs in the background. It is resident in your computer's RAM and watches for signals before it goes into action. For example, a network daemon such as httpd, the Linux Web server known as Apache, waits for a request from a browser before it actually serves a Web page.

Daemons are often configured to start automatically when you start Linux. This process is documented at various runlevels in the /etc/rc.d directory. Alternatively, you can use a tool such as ntsysv to identify and manage the daemons that are started at various Linux runlevels. This is discussed in more detail in Chapter 4.

Network Service Daemons

Networks don't always work. Sometimes you need to restart a network daemon to implement a configuration change. Red Hat Enterprise Linux provides an easy way to control network service daemons through the scripts in /etc/rc.d/init.d. This directory includes scripts that can control installed Linux network services (and more) for everything from the Network File System (NFS) to sendmail. The actual daemon itself is usually located in the /sbin or /usr/sbin directory.

With these scripts, it's easy to start, stop, status, reload, or restart a network daemon. This is useful to implement or test changes that you make to a specific configuration file. For example, if you make a change to the Apache Web server configuration file in /etc/httpd/conf/httpd.conf, you can implement the change right away with the /etc/rc.d/init.d/httpd reload command. Other switches to these scripts allow you to stop, start, or status these services. Network service management is discussed in more detail in Chapter 9.

Exam Watch 

In Red Hat Enterprise Linux, a simpler way to reload or restart a service in the /etc/rc.d/init.d directory is with the service command. For example, to restart the httpd service, you could run the service httpd restart command.

cron

Perhaps the most important daemon is cron, which can be used to execute a command or a series of commands in a script, on a schedule. Red Hat Enterprise Linux already includes a series of scripts that are executed by cron on committed schedules in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly directories.

System crontab

The easiest way to set up your own cron jobs is through the crontab file, which can be managed through the crontab command. Users can edit their own crontab files with the crontab -e command; the root user can configure the crontab for a specific user with the crontab -u username -e command.

The general format for a crontab file can be found in the /etc/crontab script, which is used to run the scripts in the aforementioned schedule-related directories. A typical crontab entry from that file is

42 4 1 * * root run-parts /etc/cron.monthly

Five schedule fields appear on the left-hand side of each crontab entry: minute, hour, day of month, month, and day of week. The preceding line is executed at 4:42 A.M. on the first of every month, no matter what day of the week it is.

Backup and Restore

Hard drives include spinning disks and magnetic media. These are mechanical parts. By definition, all mechanical hard drives will eventually fail. If you're administering a Linux system with multiple users, you do not want to have to hear the complaints of people who know that their data is more important than yours, because you'll know that they are right. Configuring backups involves a number of strategic choices that go beyond Linux.

Using full backups, you can back up the entire drive; using incremental backups, you back up just the data that has changed since the last backup. A wide variety of media are available for backups, including tape drives, writable CD/DVDs, and other hard drives in various RAID configurations. You can back up data locally or over a network. Linux includes a number of quality tools for backups.

It's common to back up through a network to a dedicated backup server. Since you're transferring at least substantial portions of a hard drive during a backup, backups can degrade network performance for other users. So it is best to perform backups when few people are using your Linux system, which in most cases is during the middle of the night. For this reason, it's a common practice to automate backups using the previously discussed cron daemon.

Tape Backups

Using magnetic tape in Linux depends on the ftape system, using 'tarballs' to group directories into single compressed backup files. Once it is mounted, it's easy to test a tape drive; just use the mt -f /dev/tapedevice command to status, rewind, or eject the tape. If it's a SCSI tape drive, use the st command instead.

Unlike when using regular media, you don't mount a tape; you can actually use switches with the tar command to write or restore directly from the tape device. Just cite the appropriate /dev/tapedevice in the command. Just make sure you can also restore from the backup you've made.

CD Backups

Backups to CDs are made in a similar fashion, using 'iso' files instead of tarballs. The mkisofs -J -r -T -o /tmp/backhome.iso /home command can consolidate regular users' home directories from /home onto a single file. You can then record this file onto the CD with a command such as:

# cdrecord -v speed=2 dev=0,0,0 /tmp/backhome.iso

You can then store the CD and later restore the files from it just by mounting it as you would any regular CD.

Hard Drive (RAID) Backups

Hard drive-based backups are based on the system known as the Redundant Array of Independent Disks, or RAID, which is covered in more detail in Chapter 5. There are several versions of RAID that can automatically restore data once you've replaced a broken hard disk.

tar

The tar command was originally developed for archiving data to tape drives. However, it's commonly used today for collecting a series of files, especially from a directory. For example, the following command backs up the information from the /home directory in the home.tar.gz file:

# tar czvf home.tar.gz /home

This is one of the few commands that does not require a dash in front of the switch. This particular command creates (c) an archive, compresses (z) it, in verbose (v) mode, with the filename (f) that follows. Alternatively, you can extract (x) from that file with the following command:

# tar xzvf home.tar.gz /home 

gzip and bzip2

The gzip and bzip2 commands are similar-they compress and decompress files, using different algorithms. If you wanted to compress a big picture file, you could do so with one of the following commands:

# gzip big.jpg # bzip2 big.jpg

It adds a .gz or a .bz2 extension. You can uncompress from these files with the -d switch:

# gzip -d big.jpg.gz # bzip2 -d big.jpg.bz2

System Log File Management

Log files are controlled by the syslogd daemon and organized in the /etc/syslog.conf file. It is important to use log files to understand the behavior of your Linux system; deviations may be a sign of problems with recently installed service or a security breach. Basic log files are organized in the /var/log directory. For more information on system logs, see Chapter 10.



 < Day Day Up > 



RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)
RCHE Red Hat Certified Engineer Linux Study Guide[c] Exam (Rh302)
ISBN: 71765654
EAN: N/A
Year: 2003
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net