Final Exam Review Questions

Survival

• This material itself isn't that difficult.
• Its sheer breadth is the difficulty.
• This is a basic property of system and network admin: needed information must come from many sources.

Key survival traits

• 'maximum entropy' assumption: I know nothing. (hardest thing: step back from presumptions)
• Indexes: where to look for what.
  • key words => sections of notes or books.
  • relationships between different aspects.
• Self-criticism: ability to look at an answer a second time, and do 'sanity checks'.

Steps in solving a problem

• list things you know.
• list things you don't know.
• attempt to fill in details.
• from all of this, synthesize a coherent procedure.

Part 1: short answer

1. You have a new daemon food that will answer requests on tcp port 5010 by ordering requested pizza. This daemon will be called under control of inetd. List all changes you need to make in order to install this daemon manually and get it to start answering requests.
2. You have a new daemon knird ('drink' backwards) that orders soft drinks. It answers requests to udp port 5020. It will run 'standalone'. List all changes you need to make in order to install this daemon manually and get it to start answering requests.
   • what you know:
     • need a startup script.
     • original script in /etc/rc.d/init.d
     • symlink to original script in /etc/rc.d/rc?.d, ?=0,1,2,3,4,5
     • entry in /etc/services.
   • what you don't know:
     • contents of script.
     • priority of startup (dependencies)
     • where file is located.
   • solution:
     1. figure out where to put the file.
     2. put it there and make it executable.
     3. figure out which user should execute the daemon.
     4. put an appropriate script into /etc/rc.d/init.d (by copying and modifying another), e.g., /etc/rc.d/init.d/knird
     5. put an entry for knird, udp port 5020, into /etc/services.
     6. figure out which services depend upon this one.
     7. from that, figure out which run level to start it at, and where in run level e.g., S64knird
     8. ln -s ../init.d/knird /etc/rc.d/rc?.d/S??knird
     9. reboot to test.
3. You don't want anyone but users on your home machine to be able to utilize food or knird. Describe system configuration changes that will keep people from other machines from accessing the daemons.
   • hosts.allow: tcp wrappers
     • wrap daemon in inetd.conf (substitute /usr/sbin/tcpd for daemon) -or-
     • modify the source code with libwrap.a
   • ipchains
     • filter the port; limit access to particular hosts.
   • similar filtering at router.
4. Can a change in file protections affect access to a daemon? Why or why not?
5. How do you send a HANGUP signal to a process, and how is it generally interpreted? Is this a hard and fast rule or not?
6. I just got a software package in the file foo.1.1.tar.gz. How do I proceed to install it?
7. Give all the steps in mounting a directory foo:/local/bar on another host taz, including how to make the mount survive a reboot.
8. Give the exact ipchains commands necessary to reject all packets from the external host 130.64.23.4, while accepting all others.
   • external host => input chain
   • action is to REJECT packets (--jump REJECT)
   • host to block is SOURCE (--source 130.64.23.4)
   • ipchains --add input --source 130.64.23.4 --jump REJECT
   • ipchains --policy input ACCEPT

Part 2: essay or long answer

1. Best practices: the emphasis of the following group of problems is to test whether you can document the proper way to proceed in a troubleshooting situation, so that another person (perhaps your employee) can proceed to repair the problem.
   1. Give a decision tree for determining whether a machine requires a specific network service in order to boot. What tests would you make, and how would you react to each test?
      • shut down service, try to boot!
        • works: service isn't needed.
        • fails: need either service or something that needs it.
      • where does boot die?
      • which script in /etc/rc.d/init.d?
      • which line?
      • what does it do? (hit manuals)
      • do I need it?
        • no: comment out.
        • yes: continue looking for dependencies.
      • is there a local service that depends upon it? (from manual)
      • is that service running or not?
   2. Give a decision tree that would describe your reaction to the message bar: Command not found. What tests would you make, and what would you do based upon each test result?
   3. You have a linux host that doesn't boot but you think the hardware is OK. Describe a decision tree of the tests you'll make to determine the problem and what you'll do in response to each kind of test result.
   4. A user calls up with a 'broken linux workstation'. Describe your interactions with that user as a decision tree. What questions would you ask and what would you do in response to each answer?
   5. Your ftp server isn't accessible from the Internet. Give a decision tree of the tests you'd make and your actions based upon each outcome.
      • start at host that can't see it.
      • can you ping server by number?
        • YES: routing's OK.
        • NO: use traceroute to fix routing.
      • can you ping server by name?
        • YES: bind is OK.
        • NO: find and fix nameserver.
      • probe ftp port (with telnet)
        • get response: no firewall problems.
        • no response: look for filter on ftp.
2. Methodologies: the following questions test your understanding of specific processes and solutions.
   1. Explain how the patch command allows one to efficiently incorporate changes into source code.
   2. Explain the difference between L and R file modes in the tripwire configuration file, giving situations in which each would be appropriate.
   3. Explain why giving root access to many people is a bad idea, and how sudo addresses this problem.
   4. Explain the concept of one-time passwords, including the principles behind implementation of opie. Then explain how one implements use of opie for protecting ftp services.
   5. You have a firewall between you and your imap server that allows only ssh traffic through. Explain what you'd do to avoid the firewall, and what if any possible security risks there are to doing it.
      • technique: ssh tunnelling. set up server ssh session to tunnel imap data.
        • set up ssh to forward localhost:imap to server behind firewall
        • point imap client at localhost:imap
      • cleartext password (required for imap) is encrypted.
      • security risks: only encrypts the last hop between localhost and server behind firewall. If user is clever enough to be talking TO the client through, e.g., telnet, the password is still at risk.
   6. Identify all places in which a 'shell alias' such as

       alias m more
      

      can be defined within the user environment.
      • tcsh:
        • ~/.login
        • ~/.cshrc
        • /etc/csh.cshrc
        • /etc/csh.login
        • or any script sourced by any of these.
        • or manually at the command line.
      • bash
        • ~/.bashrc
        • /etc/bashrc - aliases and shell settings.
        • /etc/profile - environment variables.
   7. Under what conditions can a service provided by a server function correctly even though no daemon appears to be running as a process?
      • Daemons invoked by inetd do not appear in the process table until service is requested from some machine. Daemons with attribute 'nowait' have really short runtimes and you might not see them in ps even if you try it while they're running. Inetd feels free to schedule several at once. Daemons with attribute 'wait' stay running a bit longer so that you can see them. Inetd knows that because these use more resources, it should only schedule one copy at a time.
3. Breadth: These questions test your breadth of understanding of the relationships between concepts.
   1. Compare and contrast cfengine and rdist as file distribution mechanisms. What are the relative strengths and weaknesses of each?
      • rdist:
        • server-push.
          • server must know machine details.
          • can mess up whole network with one command.
        • master server needs root on clients.
          • security risk.
        • dead hosts hang server.
        • command syntax is not obvious.
        • centered around file copying.
        • can't do something BEFORE copying a file (no antecedents)
      • cfengine:
        • client-pull
          • client knows its own config.
          • one client at a time => safer.
        • master doesn't need root.
          • LESS security risk.
        • dead hosts don't hang. cfengine doesn't run on them.
        • command syntax is neurotic.
        • begins to be service-centered (not file centered).
        • can do most anything to distribute a file.
   2. Explain why one has to set "environment variables" for particular software packages (such as, e.g., cfengine) to work. Why do environment variables change program execution, and why is it not necessarily a good idea to set all of them when the user logs into the system initially?
      • programs 'inherit' environment variables from invoking shell.
      • easiest mechanism to specify user customizations. (e.g., CFINPUTS tells cfengine where to find data)
      • usually a direct relationship between environment vars and command-line arguments.
      • difficulties
        • it takes time to set them upon login
        • they can conflict, e.g., PRINTER might be B&W for one program, color for another.
   3. Explain the basic ideas behind portability of software between UNIX implementations. What can change in the compilation environment, and how does one cope with the changes?
   4. You're given a new version of UNIX, "FOOLIX", that may or may not be compatible with the one to which you're accustomed. How do you go about catalogueing the differences?
      • user interface
        • environment variables
        • command line arguments and usage
        • boot sequence/daemon startup
      • locations of files and programs
        • library paths
        • command paths
        • databases
        • directory structure standards and meanings
        • names of devices
      • command usability/portability
        • include files
        • libraries and library structure
        • compilation tools
        • package management
   5. Explain the tradeoffs in dynamic or static linking of program libraries. What are the advantages and disadvantages of each approach?
      • static linking:
        • self-contained.
        • don't link at runtime.
        • big executable
        • libraries aren't shared.
      • dynamic linking:
        • LD_LIBRARY_PATH: dynamically linked executable with DYNAMIC path.
          • if you change library position, change LD_LIBRARY_PATH.
          • can move around libraries without problems.
        • -L/lib/dir : dynamically linked executable with STATIC path.
          • library position is hard-coded into executable.
          • must recompile in order to move a library.
        • dynamically linked libraries are SHARED among all executables that link them => less memory usage.
        • slower to invoke, because they have to be linked WHEN EXECUTED. => There's a time/space tradeoff: sharing versus speed of invocation.
   6. Explain how the data from a network snooping operation is modified by operating in a switched rather than routed environment.
      • Disadvantage of a traditional routed environment with hubs is that every host on a hub actually receives every packet that any host sends. They're all on the same wire, and only one can talk at a time. Hosts for which a message is not intended simply ignore it.
      • Switches 'learn' the ethernet/ip addresses (arp table) for each of their connections, and only send packets to connections likely to contain the recipient. This means that hosts not involved in a conversation don't receive it.
      • Result is that
        • snooping on conversations is much more difficult.
        • improvement in bandwidth based upon number of simultaneous conversations the switch can handle.
   7. Why is it that only root can make hard links to directories?
      • This is not a bug but a protective feature. While it's 'safe' to hard-link files to files, hard-linking directories allows one to create a cycle in the filesystem tree.

         cd /
         mkdir foo
         cd foo
         mkdir bar
         cd bar
         ln -h ../../foo cat
        

        • usefulness of hard links.
          • some programs refer to /usr/lib, others to /usr/ucblib.
          • put everything into /usr/lib, ln -h /usr/lib /usr/ucblib