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 very useful feature of Red Hat/CentOS 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 in the past:

      [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. Schedule a periodic job with cron

    Log in as root. Use crontab -e to create and edit a crontab file for root. Note that it will likely use the vi editor. ":q" (without the quotes) is how to quit. If you want it to use emacs instead, type export EDITOR=emacs before running crontab. Add a crontab entry that will run the uptime command every minute for today only, and capture the output by appending to a file in /var/log. For example,

      uptime >> /var/log/uptime.log

    Then save and quit your editor. Later in the lab, take a look to see the results in this log file.

    Look in /var/log/cron to see what cron has been doing. What scripts are run daily?

  3. Try out signals

    Start the firefox browser. From a shell, use ps aux to find the PID for firefox. Now use the kill command to stop the firefox process; what happens when you move the firefox window around or click on its menus? Now send it the continue signal, and notice that it recovers. This is essentially the same situation if you were to press ctrl-z at a shell that is currently running some program (like emacs) which then stops functioning (because it has been suspended).

  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 an open xterm window with the specified colors;
    2. tell me what RPM now stands for;
    3. tell me how you continued your stopped Firefox;
    4. show me the contents of /var/log/network-startup.log; and,
    5. show me your /var/log/uptime.log file, and tell me what scripts are run daily by cron

    Once you have completed the lab, you might want to take a look at homework #2, which is due Sunday.


This page can be reached from http://www.cse.lehigh.edu/~brian/course/2016/sysadmin/labs/
Last revised: 4 February 2016.