Today we have a variety of things to accomplish.
On RHEL and Fedora, 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 RHEL/CentOS CDs, we could find the right packages. 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 the 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 emacs. For that, we can type yum install emacs. Here's what happened when I did that:
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 a configuration tool) asks for the root password to let you run it. At the command line (shell prompt), instead you would typically type:
to get a root 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.
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 continnue. When I ran this, I found 12 packages that needed to be updated (including OpenOffice packages and X-Windows packages). 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 and updated the rest of your system, we can go on.
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 apmd 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 link to a bash reference, and CR chapter 8 covers bash as well.)
It might be helpful to have such a record of which physical machine you were using at which time, so 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 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.
CUPS can just make it possible for you to send print jobs to a remote print services, or it can let you configure a print service supplied by your machine as well. Look at the Linux page on http://caxton.eecs.lehigh.edu/. The command line instructions tell you how to do the former (enable access to one of the printers, but not set up a printer service (one that can queue, pre-process, convert, etc. before sending to a printer). There are multiple ways of configuring a printer. One is to use the CUPS web-based interface, available at http://localhost:631/ on machines running CUPS locally (such as your Sandbox lab machine). Note that you can change CUPS to permit remote access, too, if desired. Another is to use the provided printer configuration tool (type system-config-printer or choose Printing from the System Settings menu under Desktop), as described in CR, Chapter 4. In any case, the printer is always on caxton, and normally you would use the generic PostScript printer driver.
Use whichever mechanism you like to add the pl122-ps printer to your system and print some file (preferably one that is useful to you) to show me at the end of the lab. I suggest that you NOT use the standard printtool testpages as when you pick it up since you won't be able to tell if it is yours or someone else's. You could create a short text file and print that instead. The way I print from the command line is lpr -Ppl122-ps filename.ps (assuming you named your printer service as pl122-ps and have a postscript file called filename.ps).
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.