CSE 265: System and Network Administration

Lab #3

Today we have a variety of things to accomplish.

1. RPMs, updates, and installing packages

   First, don't run the graphical update application. That is, we no longer want to use the graphical interface for updating packages. In general, it is too easy to apply updates without thinking. While this may be the best bet for users who don't have a sysadmin to think for them, it is not ideal for us. We need to learn the command line version as well.

   Last week we installed the OS, along with many other packages. Some of you might have noticed that emacs was not installed by default. This is certainly not desirable, as I am an emacs user, and typically it is installed by default as part of the editors package. So today, we will install emacs.

   On RHEL/CentOS, all the files distributed with an application are organized into a package, with a filename ending in .rpm. (RPM used to stand for Red Hat Package Manager, but is no longer Red Hat specific.) The rpm utility can be used to install rpm files (thus installing some package).

   The next question is then of where to get an emacs rpm package. If we were to mount and examine the full RHEL/CentOS install discs, we could find the right packages. We could go to a RHEL/CentOS repository and find the rpms there. We could also look online with Google or rpmfind.net or a number of other places and likely find files providing emacs in the rpm format. But the ones we find may be old, or for other Linux distributions.

   A relatively recent, yet very useful feature of Red Hat/Fedora is support for a system called yum. yum provides the ability to remotely access rpm repositories and use rpm to install or update packages that it downloads.

   For the moment, we are interested in installing the rpm containing emacs. For that, we can type yum install emacs. Here's what happened when I did that:

   [brian@sandbox ~]$ yum install emacs
   Loaded plugins: fastestmirror, refresh-packagekit, security
   You need to be root to perform this command.

   This happened to me because I had logged in as the non-root user. While I could log in as the root user instead, it is not recommended as it is too easy to break things accidentally. Instead, it is much better to be a non-root user, and occasionally become root when necessary. Sometimes this happens automatically, as in when a program you run (such as the software updater) asks for the root password to let you run it. At the command line (shell prompt), instead you would typically type:

   [brian@sandbox ~]$ su
   Password:
   [root@sandbox brian]#
   

   to get a root prompt, typically signified by the # prompt. (Note that this way of becoming root will inherit your current path, among other things.) At that point I can now ask yum to install emacs. As you will see from my trace, yum not only installed emacs, but automatically installed three other packages that emacs requires for installation. I also had to answer one question (to go ahead with the installation). Note also when yum started up, it had to retrieve some meta data from the repository. Sometimes this can take some time, especially if there have been many updates released since yum was last run as it has to download and integrate information about them.

   You should install emacs now in the same way that I did. I also installed the xterm package (a terminal emulator for the X Window System), as I often like it better than the default terminal application. Install xterm in the same way, and then figure out how to get an xterm running with a black background and tan characters.

   We can also use yum to update packages that have newer releases (bug fixes, security patches, new features, whatever). For that, we can type yum update which will download the headers for whatever packages (that are currently installed) that have been updated. As before, yum asks whether to continue. Depending on when you last updated your machine, you may have packages that need to be updated. If you do have packages to be updated, go ahead and say yes (realizing that hundreds of MB may take a little while to download if the repository server you are using is far away or heavily loaded).

   Once you've installed emacs, xterm, and updated the rest of your system if needed, we can go on.

2. Becoming more comfortable on the command line

   We've talked in class about the importance of being comfortable at the command line. And by now, you should be comfortable with the ls and cd commands. You should also understand that in a UNIX (or Linux) filesystem, a filename can be comprised of any sequence of characters. And similarly, there really is no concept of an extension (e.g., the .doc, .txt, .xls, extensions of the Windows and to a lesser extent Mac world). Any filename can have any number of periods in it, and any sequence of characters before or after. This means that while filename extensions can be helpful to understand what is likely in the file, it cannot be guaranteed. A JPEG image file might be labelled pic.txt and the image.jpg file might contain plain text. Tip for the day: use the up arrow to bring back the next-most-recent command that you typed previously. You can then edit the previous string to become the command that you want to run now.

3. Booting into single user mode

   Now to see if you were paying attention in class. Edit (perhaps with emacs :-) your GRUB configuration file (found in /boot/grub/grub.conf) to include a second entry that boots your machine into single user mode. (I suggest also removing the rhgb and quiet options from your single user entry so that you can see what is happening as your machine boots.) Reboot your machine using telinit 6 (which has to be run as root, naturally) and test your new GRUB configuration. You'll need to press a key when grub is getting started to show you the menu. Once you are at the shell, note that using top and ps will only find processes that are part of the kernel, or any command you are running plus your shell. Typing exit will log you out of the shell (indeed, any shell), and let the machine continue to multi-user mode.

4. Startup scripts

   If necessary, go back to the course schedule and revisit the slides on booting.

   Now that you know a little about startup scripts, take a look at one of the scripts in /etc/init.d/. For example, view the cups script -- this script controls the CUPS service that we will work with below. Examine the atd script, as well -- note that they have similar structure and form, and support pretty much the same set of commands.

   Write a short and simple (bash) script that appends the current date/time and the system's hostname to the file /var/log/network-startup.log. (If you are stuck, recall that lab #1 had a links to bash references, and USLAH 2.1 covers bash as well.)

   Let's call this script every time the machine is booted. As you know, in /etc/rc.d/ there are directories for every run level, and in each directory, links to each service to stop or start. The last one to start in the multi-user runlevels is S99local, which points to /etc/rc.d/rc.local. This script (typically essentially empty) is where a sysadmin can easily customize the boot process to include additional commands. Modify /etc/rc.d/rc.local to call your script. Reboot twice to make sure that each boot gets logged into this file.

5. Wrapping Up

   In order to sign the lab completion sheet, you will need to:
   1. show me your revised grub configuration file;
   2. show me an open xterm window with the specified colors;
   3. demonstrate how to scroll through your command line history;
   4. tell me what RPM now stands for;
   5. show me the contents of /var/log/network-startup.log; and,
   6. tell me your prefered method of shutting down your CentOS installation (other than using the graphical menu selection).

   Once you have completed the lab, you might want to take a look at homework #2, which includes tasks to perform on your Sandbox drive and is due Friday.