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 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:
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:
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.
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. When I ran this, I found 33 packages that needed to be updated (including a kernel package and X-Windows packages). If you 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 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 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 link to a bash reference, 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.
For simplicity, let's use the GUI to modify the firewall. Go to System->Administration->Firewall. It brings up the firewall configuration window and asks for your root password. In the configuration window, it lists the services that can be enabled. We want three: Multicast DNS (mDNS), Network Printing Client (IPP), and Network Printing Server (IPP). After choosing them, click Apply. Yes, you are certain you want them to be set up. You can close the firewall now.
Now you can try lpstat to show the printers that your system knows about, and you'll find a long list. Generally speaking, at Lehigh many of the printers that you see are those that are made available by (un- or mis-configured) CUPS servers on Macs or Linux boxes in various research labs. The printers you want to use are the ones hosted by caxton.
Some kinds of print servers don't advertise their printers via IPP, and so you would have to tell CUPS about them explicitly. Since the printer in 122 is already visible, we don't need to do that today.
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.
At this point, we can now find an nVidia driver (look for packages with yum search nvidia). We want to install kmod-nvidia (a kernel module) that knows how to talk to the graphics card. Install it, and when you reboot, you should automatically have a proper display at the ideal 1920x1080 resolution.
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.