----------------------- Lab #09 for NET2003 due March 29, 2007 ----------------------- -Ian! D. Allen - idallen@idallen.ca Remember - knowing how to find out an answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) Global weight: 4% of your total mark this term. Due date: before 17h00 Thursday March 29, 2007 (NOTE TIME AND DATE) The deliverables for this lab exercise are to be submitted online on the Course Linux Server using the "netsubmit" method described in the lab exercise description, below. No paper; no email; no FTP. One In-Lab demonstration is needed (March 22 or March 29). Late-submission date: I will accept without penalty lab exercises that are submitted late but before 10h00 on Monday, April 2. After that late-submission date, the lab exercise is worth zero marks. Lab exercises submitted by the *due date* will be marked online and your marks will be sent to you by email after the late-submission date. Lab Synopsis ------------ Do some housecleaning to free UML memory space. Make sure ssh and three switches are started in setup.sh. Modify the VNS not to halt when the X server exits. Enable system logging in the VNS and UMLs. Enable DNS in the UML machines. In-Lab Demo - Configure and demonstrate an xinetd "daytime" service. (The initials "ALN" refer to your required course textbook - Advanced Linux Networking.) Housecleaning ------------- In the VNS base setup.sh script, do some housecleaning: 1) Have setup.sh clean the apt cache of files (not directories) we don't use: apt-get clean rm -f /var/cache/apt/* rm -f /var/cache/debconf/* Despite the "-f", you might still get a warning about a directory. You can suppress this error by sending stderr to /dev/null. more VNS base preparation ------------------------- 2) Have setup.sh make sure sshd is started and root has a password: if ! pgrep -x sshd ; then startsshd echo 1>&2 "$0: Setting root password in $(hostname):" passwd root fi 3) Have setup.sh make sure we have at least three hubs: count=$( ps xc | grep -c uml_switch ) if [ $count -lt 3 ] ; then echo 1>&2 "$0: Missing hub - please start at least three" umlHub fi Modifying the VNS not to halt when the X server (GUI) exits ----------------------------------------------------------- If you kill the X server (CTRL-ALT-BACKSPACE), the whole VNS system halts. That's annoying and unnecessary. We can fix it in the base VNS using some simple scripting. The X server is started in the VNS base machine in Run Level 5 by one line at the end of /etc/inittab that looks like this: x5:5:wait:/etc/init.d/xsession start You'll recoginze that as a standard start-up script. We can edit it: 4) Have your VNS setup.sh script edit the xsession script and remove or comment out the /bin/halt line. While one can do this using using the script commands you already know, such as "grep -v", a more elegant method uses a one-line Perl script to do the edit in-place. Add this Perl one-liner to your base VNS setup.sh file: perl -pi.bak -e 's; /sbin/halt; #/sbin/halt;' /etc/init.d/xsession Run your setup.sh script and verify that the line is commented out. The above edit doesn't solve the problem for your current X display session, since the unedited script file (containing /bin/halt) is the one *currently* executing. If we kill the X server, the shell will most likely run its cached copy of the xsession script and execute /bin/halt. We have to kill the current xsession script so that doesn't happen: 5) Have your setup.sh script locate the currently running copy of the xsession script and kill it, to prevent /bin/halt from executing: pkill -x xsession Run your setup.sh script and verify that no xsession script is running. Now, when the X server dies or exits, your system won't also halt. Enabling system logging in the VNS and UMLs ------------------------------------------- Reference: Week 8 notes. Servers need system logs. The current VNS locations for the logs aren't permanent - both VNS and UML logs go to terminal devices only. We will fix the logs to go to a directory on our virtual disk. Ensure that you have fixed /host to be a symlink to your virtual disk (to /mnt/hdb1) before continuing. The logs will use the /host path. # ls -l /host lrwxrwxrwx 1 root root 10 Mar 15 12:34 /host -> /mnt/hdb1 In both the VNS setup.sh and UML uml.sh scripts: 6) Have the script create directory /host/log to hold all the log files: mkdir -p /host/log 7) Have the script overwrite /etc/syslog.conf to log everything into the new directory: hostname=$( hostname ) echo "*.* /host/log/$hostname" >/etc/syslog.conf Note the use of double quotes to allow the $hostname variable to be expanded by the shell to be the name of this machine. The "*.*" matches everything that might be logged. 8) Have the script restart system loggers, so that they re-read the new contents of the /etc/syslog.conf file: /etc/init.d/sysklogd restart /etc/init.d/klogd restart 9) Note that "/etc/init.d/klogd stop" doesn't work in the base VNS. A bug in the VNS paths for /sbin prevents "restart" from working on the VNS base; so, insert these pkill lines before the above restart lines (insert these two lines only for the base VNS, not the UMLs): pkill -x klogd # these are needed in the base VNS only pkill -x syslogd # note the spelling of the syslogd daemon Run your setup.sh and uml.sh scripts to fix the logging. 10) Check that logging works using the "logger" command to make a log entry: # hostname vns # logger test logging # tail /host/log/vns ... Mar 15 12:34:56 localhost logger: test logging 11) Also check that "logger" works in your UML machine(s). Getting DNS working in the UML machines - ALN p.46-48 --------------------------------------- Reference: Week 8 notes. The base VNS has working DNS lookups, thanks to DHCP (pump) setting up the /etc/resolv.conf file with the IP addresses of name servers. The UML machines have an empty /etc/resolv.conf file - no DNS lookups are being done. Since we have Internet access working in the UML machines now, we can pass DNS requests to the same DNS servers used by the base VNS. 12) Have your VNS base setup.sh script copy the VNS /etc/resolv.conf (set by DHCP) to your virtual disk (use destination path /host/resolv.conf). Run setup.sh to create this file copy. Make sure it worked! 13) Have your uml.sh script check /etc/resolv.conf in the UML. If /etc/resolv.conf is missing (does not exist), or empty (zero size), or is a symlink, and if file /host/resolv.conf exists and is not zero size, remove /etc/resolv.conf and recreate it as a symlink to /host/resolv.conf on each UML machine. Run uml.sh to create this symlink. 14) Verify that you can now do "host google.ca" on your UML machine(s). In-Lab Demo - Configuring an xinetd service - ALN p.96-98 ------------------------------------------- Reference: Week 10 notes. Demonstrate to your instructor In-Lab the "daytime" service running under xinetd when you have finished configuring it and TCP wrappers. This configuration section is not required to be part of any script (though you can script it if you want to). The configuration will vanish when you restart your VNS. Show it to your instructor before you restart. 15) In Magenta, start the xinetd server and enable its "daytime" service. (See your Week 10 notes, ALN p.96-98.) Note that the "reload" and "restart" functions of the xinetd start-up script may not be as reliable as actually stopping the service and restarting it again. If a "reload" or "restart" doesn't seem to work, use "stop" and then "start". Check the system log file. 16) Check the end of the Magenta system log file to make sure that both the TCP and UDP versions of the service started (two services): Mar 21 12:34:56 magenta xinetd: Started working: 2 available services 17) Connect to the daytime service via Magenta localhost and pull out the date: # hostname magenta # nc localhost daytime 21 MAR 2007 12:34:56 EDT 18) Connect to the service via Magenta's eth3 IP address and you won't get any daytime output - the service is blocked: # hostname magenta # nc magenta3 daytime # Look in the Magenta system log file to find out why. ("libwrap" refers to the version of TCP wrappers compiled into xinetd.) 19) Fix the TCP wrappers to permit all hosts on Magenta's eth3 Class C (/24) network to access the "daytime" service. (See your Week 10 notes, ALN p.92-95.) 20) Retry the failed daytime: nc magenta3 daytime With the correct TCP wrappers entry, it should work now. 21) Verify that you can also get daytime from the Yellow UML, since Yellow shares the same Class C network as Magenta: # hostname yellow # nc magenta3 daytime 21 MAR 2007 12:34:56 EDT 22) Verify that you can *NOT* get daytime from any other UML machine interfaces. Check the Magenta log file to confirm that TCP wrappers is blocking access to the service from these foreign IP addreses. 23) Demonstrate In-Lab that you have correctly configured this service to your instructor. (Show the xinetd config files, the TCP Wrappers config files, the system log file, and demonstrate that it all works.) Submission ---------- Submission Standards: See Lab #1 for details. A. Make sure all files contain an Exterior Assignment Submission label. For full marks, where possible, lines that you type must be shorter than 80 columns. B. Submit your files for marking as Lab 09 using the following *single* netsubmit command line exactly as given here: $ netsubmit 09 uml.sh setup.sh startuml.sh Always submit *all* three files at the same time for every submission. Files submitted under the wrong names are worth zero marks. C. You have one In-Lab demo to do in Week 11 or Week 12. Marking scheme: scripts: 75%, demo: 25% P.S. Did you spell all the assignment label fields and file names correctly?