Disclaimer

• I try very hard not to tell you how I think.
  • The way we think is very much a product of our environments.
  • Your environment was very different than mine.
  • My fundamental assumption is that you can `think different' and perhaps better than I.
• So it is with some trepidation that I expose how I think about this field.
  • As they say in the Gnu Public License: "This information is provided in the hope that it will be useful, but without any warranty, even implied warranties of merchantability or fitness for any particular purpose."

Creating a discipline

• I consider all of these notes an experiment in creating a discipline.
• A discipline is nothing but an empowering way of thinking about a set of (otherwise disorganized) facts.
  • organizes what we know into a coherent `body of knowledge'.
  • simplifies memorization and application.
  • perhaps embraces assumptions that limit complexity of problems and solutions.
• We have a discipline when many people agree with our methods.
  • I'll start the game by telling you how I organize my thinking.
  • You can help by telling me ways that you use to simplify problem solving.

Onion Peeling

• Top-down model of knowledge.
  • Start at top, peel away layers as needed.
• Organize information by refinement.
  • Top level: intentionally oversimplified model.
    • just basics.
    • no frills or special cases considered.
    • asterisks mark where things are more subtle.
  • Detail level: refinement of initial model.
    • add features.
    • clarify special cases.
• sort of like revision control that we studied in a previous lecture.

The top level: sanity checks

• are we doing something reasonable?
• is it naively correct?
• my `cheat sheet'.

Files and Directories

1. All files are stored in inodes.
2. Inode number uniquely identifies file.
3. A directory is just a special kind of file that contains names for inodes.
4. .. in a directory points to containing directory (except that /.. is /).
5. To derive a name for an inode, follow ..'s all the way to /.

Protections

1. Protection of a thing determines what you can do with the content of the thing.
   1. r: can read it (ls).
   2. w: can write it (edit).
   3. x: can execute it (or search it for a name).
2. Whether you can rm or create a file is determined by the protection of the immediate parent directory.
3. Whether you can access a thing is determined by all components of the full path to it.

Filesystems

1. start with `unformatted' storage device.
2. create filesystem on device with newfs.
3. mount filesystem on directory.
4. fsck filesystem to correct errors.
5. umount filesystem to stop using it.
6. df to check status of mounts.
7. kinds of filesystems:
   1. local: on device (ext2)
   2. remote: on network (nfs)

Processes

1. Every process is a descendant of init.
2. Every process has a process id that identifies it.
3. Environment variables are inherited by children.
4. When a child dies, environment is not transferred back to parent.
5. Communicate with processes via kill command
   1. actually sends signals
   2. HUP (-1): hangup; `re-read databases'.
   3. KILL (-9): die now.
   4. TERM (-15): die when convenient.

Environment

1. PATH: where to find programs
   1. list of directories containing candidate programs.
   2. all programs executable by you become available.
   3. first match wins.
2. MANPATH: where to find man pages
   1. like PATH but for man pages.
3. LD_LIBRARY_PATH: where to find libraries
   1. like PATH but for libraries.

Networking

1. To understand a an IP networking problem, first identify the logical wires.
2. Each logical wire must have a distinct network address.
3. (Net address) = (IP address) & (Subnet mask) (bitwise and).
4. (Broadcast address) = (IP address) | ~(Subnet mask) (bitwise or).
5. available addresses between (Net address) and (Broadcast address)-1
6. The ARP table describes only IP-to-MAC addresses for directly connected wires.
7. Routing table gateways must be addressed on directly connected wires.
8. Routing targets can be anywhere.
9. meaning of RIP information is based upon the router that sent it.

Refinement

• Start with a naive description.
• Add exceptions/detail.
• Until you can solve a problem.
• Easy example: network.

MAC address:

• local
• not known except by directly connected machines.
• describes hardware
• 6 hex bytes.
• first 3 assigned to vendor.
• last 3 describe product (refer to network card)

IP address:

• assigned by internet numbering authority
• 4 unsigned decimal bytes.
• 10., 192.168., 172.27. private (not routed on internet)
• everything else assigned.

Name:

• consists of domainname and hostname.
  • foo.eecs.tufts.edu has hostname foo, domainname eecs.tufts.edu
• name to IP map reported by domain name service (DNS).
  • forward map: from name to IP.
  • reverse map: from IP to name.

ARP protocol/tables

• arp maps between IP and MAC addresses.
• arp tables contain interfaces on the same wire

Routing tables

• contain target subnet and next hop (gateway)
• target subnet can be anywhere
• gateway must be on same wire as some interface.

RIP

• RIP packets contain subnets that sender can get to
• metric: how many hops.
• subnet: where we can get to.

Services

• port number describes kind of service (0-65535)
• /etc/services maps between post numbers and names.
• specific service is identified by pair (IP, port)
• service connection described by (IP, port) for both server and client.

Difficult example: shell startup

• Alas, the network, files, protections, etc, are rather closed bodies of knowledge.
• Thus refinement ends rather quickly.
• How does one deal with an open-ended thing such as a startup script?
  • can do most anything.
  • many manuals involved in understanding function.
  • no `traditional' aids to understanding, as in normal programming.

Need a new model of knowledge

• need a way to forget detail.
• need a way to be able to compare things that are different.
• don't have subroutines.

New concept: algorithmic skeletons

• show what's happening inside an algorithm at varying levels of detail.
• skeleton: crucial aspects of the thing; exterior structure.
• details vary; skeletons remain.

Structured abstraction and descent

• decontextualize crucial aspects from each script you need to understand.
• simplify until you understand them.
• recontextualize as needed to construct true complexity of a real script.

Step 1: form a naive model

1. Runlevel between 0 and 6
   1. 0: halted
   2. 1: single-user
   3. 3: multi-user
   4. 6: reboot
2. scripts in /etc/rc.d/rc[0-6].d say what to do.
   1. K[0-9][0-9]something: stop something
   2. S[0-9][0-9]something: start something
3. these are symlinks to scripts in /etc/rc.d/init.d
   1. two possible arguments: start and stop.

Step 2: refine this model

1. /etc/rc.d/rc:

    runlevel=3
    for s in /etc/rc.d/rc$runlevel.d/K??*; do 
      $s stop
    done
    for s in /etc/rc.d/rc$runlevel.d/S??*; do 
      $s start
    done
   

2. a typical startup script:

    pid=`/bin/ps -e | /bin/awk '$4=="foo" { print $1 }'`
    case $1 in 
      start) 
       [ $pid = '' ] && [ -x /usr/sbin/foo ] && /usr/sbin/foo &  
       ;; 
      stop) 
       [ $pid != '' ] && /bin/kill $pid  
       ;; 
      *) 
       echo "usage: foo {start or stop}"
   

Step 3: refine more as necessary

1. /var/lock/subsys/* contain lockfiles for subsystems.

    pid=`/bin/ps -e | /bin/awk '$4=="foo" { print $1 }'`
    case $1 in 
      start) 
       [ $pid = '' ] && [ ! -e /var/lock/subsys/foo ] \
                     && [ -x /usr/sbin/foo ] \
                     && /bin/touch /var/lock/subsys/foo \
                     && /usr/sbin/foo &  
       ;; 
      stop) 
       [ $pid != '' ] && /bin/rm -f /var/lock/subsys/foo \
                      && /bin/kill $pid  
       ;; 
      *) 
       echo "usage: foo {start or stop}"
   

2. add functions to kill process or start daemon:

    #! /bin/sh
    
    # Source function library.
    . /etc/rc.d/init.d/functions
    
    # Get config.
    . /etc/sysconfig/network
    
    # Check that networking is up.
    if [ ${NETWORKING} = "no" ]
    then
            exit 0
    fi
    
    [ -f /var/local/ssh/sbin/sshd2 ] || exit 0
    
    RETVAL=0
    
    # See how we were called.
    case "$1" in
      start)
            echo -n "Starting sshd: "
            daemon /var/local/ssh/sbin/sshd2
            RETVAL=$?
            echo
            [ $RETVAL -eq 0 ] && touch /var/lock/subsys/sshd
            ;;
      stop)
            echo -n "Stopping sshd services: "
            killproc sshd2
            RETVAL=$?
            echo
            [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshd
            ;;
      status)
            status sshd2
            RETVAL=$?
            ;;
      restart|reload)
            $0 stop
            $0 start
            RETVAL=$?
            ;;
      *)
            echo "Usage: $0 {start|stop|status|restart|reload}"
            exit 1
    esac
    
    exit $RETVAL
   

3. here's where it gets complex: functions call others:
4. A function to stop a program.

    killproc() {
      RC=0
      # Test syntax.
      if [ $# = 0 ]; then
        echo "Usage: killproc {program} [signal]"
        return 1
      fi
   
      notset=0
      # check for second arg to be kill level
      if [ "$2" != "" ] ; then
        killlevel=$2
      else
        notset=1
        killlevel="-9"
      fi
   
      # Save basename.
      base=`basename $1`
    
      # Find pid.
      pidlist=`pidofproc $base`
    
      pid=
      for apid in $pidlist ; do
         [ -d /proc/$apid ] && pid="$pid $apid"
      done
   
      # Kill it.
      if [ "$pid" != "" ] ; then
        [ $BOOTUP = "verbose" ] && echo -n "$base "
        if [ "$notset" = "1" ] ; then
          if ps h $pid>/dev/null 2>&1; then
            # TERM first, then KILL if not dead
            kill -TERM $pid
            usleep 100000
            if ps h $pid >/dev/null 2>&1 ; then
              sleep 1
              if ps h $pid >/dev/null 2>&1 ; then
                sleep 3
                if ps h $pid >/dev/null 2>&1 ; then
                  kill -KILL $pid
                fi
              fi
            fi
          fi
          ps h $pid >/dev/null 2>&1
          RC=$?
          [ $RC -eq 0 ] && failure "$base shutdown" || success "$base shutdown"
          RC=$((! $RC))
          # use specified level only
        else
          if ps h $pid >/dev/null 2>&1; then
            kill $killlevel $pid
            RC=$?
            [ $RC -eq 0 ] && success "$base $killlevel" || failure "$base $killlevel"
          fi
        fi
      else
        failure "$base shutdown"
      fi
    
      # Remove pid file if any.
      if [ "$notset" = "1" ]; then
        rm -f /var/run/$base.pid
      fi
      return $RC
    }
   

   • what's really going on here?
   • killproc does a lot more than kill.
   • mainly to assure that the process is `sincerely' dead.
5. but it's not over yet:
6. A function to find the pid of a program.

    pidofproc() {
      # Test syntax.
      if [ $# = 0 ] ; then
        echo "Usage: pidofproc {program}"
        return 1
      fi
   
      # First try "/var/run/*.pid" files
      if [ -f /var/run/$1.pid ] ; then
        pid=`head -1 /var/run/$1.pid`
        if [ "$pid" != "" ] ; then
          echo $pid
          return 0
        fi
      fi
    
      # Next try "pidof"
      pid=`pidof -o $$ -o $PPID -o %PPID -x $1`
      if [ "$pid" != "" ] ; then
        echo $pid
        return 0
      fi
    }
   

   • what's going on here?
   • avoid calling 'ps'!
   • call another function to do that if necessary.
7. Gasp! Another function pidof: see man pidof for details.