NOTES of Interest

• All student materials are to be uploaded (uploaded or a link) to your twiki page.

  

• Multipage documents SHOULD have a PAGE number.

  

• There is NO example of a lab writeup.
  Each lab has different results. You need to format those results so that I or a grader can determine that you understand what is happening. For example, you can cut and paste material from a screen or even take a screen shot. You can then write comments about (or on) that material and upload. As far as answers to questions, you should provide both the question and the answer or incorporate the question in your answer.

Tech NOTES of Interest

DNS lives at: /mnt/dns

ports live in /etc/services

CS-Wide Traffic The best source is to run Wireshark on Knuth (i.e., run ssh -Y username@knuth.cs.hmc.edu wireshark from a machine that has X11 installed) All of Knuth's traffic should be visible (mostly SSH, LDAP, NFS, and DNS, of course, but also a certain amount of NTP, HTTP, IPP, and random other stuff) as well as traffic from the two virtual machines running on Knuth: Vilkes (the VM that should be replacing the decade old Wilkes hardware at some point) and Parchmon (a Windows 10 virtual machine that monitors usage/supplies/errors on the Xerox copier and periodically reports back to the company we lease it from). Also, all the usual random broadcast/multicast traffic: ARP, IPv6 Neighbor Discovery, Simple Service Discovery Protocol (a UPnP thing that Parchmon is constantly doing), Dropbox LAN Sync, NetBIOS Name Service (Windows), MDNS, DHCP, STP, LLDP, etc.

DNS & DHCP
On VLAN 42fixed IPv4 addresses are used. That includes CS lab Macs. Addresses are assignedto the Macs with DHCP, but the DHCP server has a table mapping MAC addresses to IP addresses, so it always hands out the correct (and same) address to each machine. This is also why you cannot just plug a random machine into VLAN 42 and get an address; if the DHCP mapping does not have an address for your MAC address, then you don’t get an address. On VLANs 40, 41, and 43 we hand out random addresses to anyone who asks for one. There is a standard for dynamic DNS (RFC 2136) where hosts can register changes to DNS whenever they get a new IP address, but we don’t currently use it for that. (We do use RFC 2136 for some other stuff, e.g., creating temporary TXT records for performing dns-01 challenges (https://tools.ietf.org/html/draft-ietf-acme-acme-14) and to request TLS certificates from letsencrypt.org.)



• X11
  
  Recent versions of OS X, no longer have X11 installed by default. You can find X11 at http://xquartz.macosforge.org/trac/wiki [XQuartz Project page].
  To test if X11 is already supported on your machine, try to run xterm on a local terminal window. See https://support.apple.com/en-us/HT201341 for information about X11 support on Macs.
  In the Rock Lab, X11 should be installed. But you will need to pass the -Y flag to ssh as it is not configured to do X11 by default. E.g., ssh -Y user@knuth

TOOLS of Interest

• code2html takes code and converts to HTML.

  

• SSHFS make files locally accessible.

  

• Using Your Own Machine
  The easiest way to work on your own machine is just to connect to the CS servers. That way, all your files are on the CS file servers (and thus backed up) and all the software you need is readily available. In essence, your machine becomes a graphical terminal connecting to the remote system. But feel free to work on your own machine and upload to the twiki.
  
  Linux and OS X
  Open a terminal and run

  ssh -X ‹your-id›@knuth.cs.hmc.edu
  

  where ‹your-id› is your id (e.g., if your id is mjones, use ssh -X mjones@knuth.cs.hmc.edu).
  The -X option causes ssh to also forward X11 traffic, allowing you to run graphical programs (e.g., editors, viewers, etc.) on knuth and see them shown on your screen. For example, run xterm after logging in to bring up a terminal window for the remote machine.
  Some programs are not written to correctly take advantage of the X11 SECURITY extensions and will not work properly when logging in with ssh -X, in which case you might want to try forwarding X11 traffic using ssh -Y instead, which enables trusted X11 forwarding and will work better for some applications. Be warned that connections using trusted X11 forwarding will not be subject to X11 SECURITY controls and should not be used when logging in to untrusted machines.
  Note: if you are running a recent version of OS X, X11 is no longer installed by default. You can find it on the [[http://xquartz.macosforge.org/trac/wiki][XQuartz Project page]].
  To test if X11 is already supported on your machine, try to run =xterm= on a local terminal window. See [[https://support.apple.com/en-us/HT201341]] for information about X11 support on Macs. -- Main.KateAplin - 01 Sep 2015

SOCKETS

Socket Man Pages
now in: man -s3socket
Compile Problems:
Link in nsl and socket
A number of people have reported problems with closing down the server and getting the port back.
Basically the rule is:
1. close the client
2. then close the server

Any other order is problematic.
Because, if you close down the server first, TCP will not shut down because it has an open connection to the client. TCP has a built in timer, so it holds onto things until that timer fires. This is exactly why synflood attacks work. Thus your port will not be released for a period of time.
Good overview of sockets.... http://www.ecst.csuchico.edu/~beej/guide/net/

Mike Erlinger