Added initial support for Xen 4.1 vnodes with an Ubuntu 12.04 dom0.
Basic stuff is working, but none of the networking stuff has been
tested yet.

- /etc/dhcp/dhcpd.conf will be used in preference to /etc/dhcpd.conf
  if the directory /etc/dhcp is present or /etc/dhcp/dhcpd.conf is
  present.  Debian-ish distros put the dhcpd config in /etc/dhcp.

- Restarting dhcpd on upstart-based systems is now supported, as
  is calling the dhcpd service 'isc-dhcp-server' instead of just
  'dhcpd'.

- Remove hardcoded paths to /usr/sbin/lvcreate; some distros keep
  lvm2 binaries in /sbin.

- Output of 'xm info' is parsed and cached so that libvnode_xen
  can support both Xen 3.x and 4.x.

- If we're running under Xen 4.x, use /dev/xvda for the guest root
  disk, not /dev/sda.

- If copying the dom0 root fs to create the domU root fs, copy
  everything, not just certain directories.  Ubuntu 12.04 refused to
  boot without everything there.  Hardcoding the additional paths
  won't work, since older distros don't have them (/run, for example).

- The default domU kernel should be symlinked to /boot/vmlinuz-xenU.
  Likewise, the initrd (if any) should by symlinked to
  /boot/initrd-xenU.  These were previously hardcoded to the values
  used by the Fedora 8-based dom0 image.

- Cleaned up some bashisms in /etc/xen/scripts/emulab-cnet. Ubuntu
  uses dash for /bin/sh, and it doesn't support bash's extensions
  to Bourne shell syntax.

- Remove additional state from the domU fs when creating it from dom0:
  dhclient.leases, /var/run/cnet, mtab, swap entries in fstab.

- Fix iptables rules for preventing dhcp broadcast packets from going
  through the bridge.

FreeNAS is basically a web frontend to BSD-backed ZFS volumes,
filesystems, and various ways to share them (i.e., iSCSI, NFS, etc).
It stores all its config info in a sqlite DB from which it configs
the BSD system.  It uses Django (a slightly weird MVC that exports a web
interface; logic/models/views are all in python, and there is an
HTML-based template interface.

What I did was basically to wrap the model/form parts of FreeNAS's
code -- so for the commands we want to support, we actually mock up
an HTTP request, and submit it directly to the correct handler function
that the FreeNAS Django config files specify.  This allows us to leverage
all the FreeNAS error checking code and automation (i.e., deleting an
interface would delete aliases on that interface too).

usage() prints this, at present:

Supply a command set class, an operation, and the necessary arguments.

  interface       Configure network interfaces
    add  <interface> <name> [<dhcp=X> <ipv6auto=X> <options=X> ] ...
    del  <interface>
    edit <interface> [<dhcp=X> <ipv6auto=X> <name=X> <options=X> ] ...
  ist             Configure ISCSI targets (a target binds SCSI attributes
         (i.e. serial number, r/w flags, queue depth, block size) to iSCSI
         attributes (i.e., a target portal, authorized initiator network ACLs,
         iSCSI authentication info)
    add  <name> <serial> <portalgroup> <initiatorgroup> [<authtype>
         <authgroup> ] [<alias=X> <flags=X> <logical_blocksize=X>
         <queue_depth=X> <type=X> ]
    del  <name>
    edit <name> [<serial> <portalgroup> <initiatorgroup> <authtype>
         <authgroup> ]
  ist_assoc       Associate extents with targets (final "link" between storage
         and network)
    add <target> <extent>
    del <target> <extent>
  ist_authcred    Configure ISCSI target authentication credentials (i.e.,
         users)
    add  <tag> <user> <secret1> [<peeruser> <peersecret1> ]
    del  <user>
    edit <tag> <user> <secret1> [<peeruser> <peersecret1> ]
  ist_authinit    Configure ISCSI initiator authorizations by hostname or
         network
    add  <tag> <initiators> [<auth_network> <comment> ]
    del  <tag>
    edit <tag> <initiators> [<auth_network> <comment> ]
  ist_config      Configure general ISCSI parameters
    edit [<basename=X> <defaultt2r=X> <defaultt2w=X> <discoveryauthgroup=X>
         <discoveryauthmethod=X> <firstburst=X> <iotimeout=X> <maxburst=X>
         <maxconnect=X> <maxoutstandingr2t=X> <maxrecdata=X> <maxsesh=X>
         <nopinint=X> <r2t=X> ]
  ist_extent      Configure ISCSI target extents (block devs or files exported
         via ISCSI)
    add      <name> <dev> [<comment> ]
    addfile  <name> <path> <filesize> [<comment> ]
    del      <name>
    edit     <name> <dev> [<comment> ]
    editfile <name> <path> [<comment> ] [<filesize=X> ]
  ist_portal      Configure ISCSI target portals (i.e., ip:port binding to
         associate with a target)
    add  <tag> [<comment=X> ] ...
    del  <tag>
    edit <tag> [<comment=X> ] ...
  network         Configure generic network settings
    config [<domain=X> <hostname=X> <ipv4gateway=X> <ipv6gateway=X>
         <nameserver1=X> <nameserver2=X> <nameserver3=X> ]
  pool            Configure ZFS storage pools
    add <volume_name> <volume_fstype> <group_type>  ...
    del <vol_name>
    mod <volume_add> <volume_fstype> <group_type>  ...
  route           Configure static routes
    add <destination> <gateway> [<description> ]
    del <destination> [<gateway> ]
  snapshot        Create, clone, rollback ZFS snapshots of volumes or clones
    add      <snap_name>
    clone    <cs_snapshot> <cs_name>
    del      <snap_name>
    rollback <snap_name>
  vlan            Configure vlan interfaces
    add <pint> <vint> <tag> [<description> ]
    del <vint>
  volume          Configure ZFS volumes (zvols) atop pools
    add <pool_name> <zvol_name> <zvol_size> <zvol_compression>
    del <pool_name> <vol_name>

and provide a web interface to look at them.

For InstaGeni, need to record and be able to search for history by
control net mac address. We now record this in the node_history table,
with corresponding change to the ShowNodeHistory web page.

The backend changes required are that we 1) actually generate a mac
address for VMs and stick it into the interfaces record, 2) return
that mac from tmcd in the jailconfig, and 3) have the openvz library
create the control net interface using that mac.

On the openvz image, needed to switch to using a control network
bridge for all interfaces (not just routable ones) so that traffic
leaves the node with the correct mac.

not 000000000000.

address that is assigned. For ProtoGeni.

* Get rid of all use of component_hops; this was our original syntax
  before the stitching path stuff was nailed down.

* Allow a vlan tag to be requested in the link statement:

    <link client_id="link0" vlantag="765">
      <interface_ref client_id="geni1:if0" />
  
* Support vlan tag requests in the stiching path part:

    <vlanRangeAvailability>765</vlanRangeAvailability>
    <suggestedVLANRange>765</suggestedVLANRange>

  This is the only support at the moment; none of the range stuff is
  done. Further, if you really want things to work, make sure all the
  hops have the same vlan tag cause we don't do vlan translation
  internally or at our edge points.

* Utah only change in the mapper; when trying to use a shared vlan
  whose tag is great then 1000, demand the "highvlan" feature on the
  nodes in the lan. Only some of our switches to high numbered vlans.

that are in the reserved_vlantags table, but are not referenced
by an actual lan object in the lans table.

We had a couple of different problems actually.

* We allow users to insert html into many DB fields (say, a project or
  experiment description).

* We did not sanitize that output when displaying back.

* We did not sanitize initial page arguments that were reflected in the
  output (say, in a form).

Since no one has the time to analyze every line of code, I took a couple of
shortcuts. The first is that I changed the regex table to not allow any <>
chars to go from the user into the DB. Brutal, but in fact there are only a
couple of places where a user legitimately needs them. For example, a
startup command that includes redirection. I handle those as special
cases. As more come up, we can fix them.

I did a quick pass through all of the forms, and made sure that we run
htmlspecialchars on everything including initial form args. This was not
too bad cause of the way all of the forms are structured, with a
"formfields" array.

I also removed a bunch of obsolete code and added an update script to
actually remove them from the www directory.

Lastly, I purged some XMLRPC code I did a long time ago in the Begin
Experiment path. Less complexity, easier to grok and fix.

	modified:   sql/database-fill.sql
	modified:   sql/dbfill-update.sql

The code to determine what ports need to be trunked or untrunked was
blindly picking all ports for the experiment, instead of restricting
them to those in the vlans being operated on. The result was a missing
device from the stack.

to libvtop.

People try to fix pc433 to pc433. The former is a node in the topo,
the later is a physical node. Causes confusion, breaks. Look for
this corner case.

Allow lans that use shared lans, to have more then one port. So now
you can do this in your rspec:

   <link client_id="link0">
     <vlan:link_shared_vlan name="openflow-mesoscale" />
     <interface_ref client_id="node1:if" />
     <interface_ref client_id="node2:if" />
   </link>

The GPO wants this for the protogeni racks. We now build reverse
map files for the 172.16 subnet, although we do it on a /16 boundry
to avoid a zillion zone files.

I am not planning to write an update script for this, since it would
require scripting changes to named.conf, which I am loath to do. So I
will do it by hand in Utah, and new sites (racks) will get it. If a
site wants it:

	boss> cd obj/named

Copy all of the 172 files to /etc/named/reverse
Copy all of the 172 zone entries from named.conf to /etc/named/named.conf

	boss> named_setup

Did the pubsub one a long time ago, but added a frisbee one as well.

The pubsub dissector has not been tested in its wireshark 1.8 incarnation,
I just converted it from the 1.2.10 version and made sure it compiled.
The frisbee dissector just supports the base UDP protocol (not the TCP
master server protocol) and doesn't implement wireshark conversations.

This last few commits were the result of a two-day trip into the weeds.
This started out as getting a hack shared 10Gb LAN working on the new 820
nodes. Then I decided to test it out by running frisbee at high bandwidth
over that LAN. Next thing you know, I'm out in the fields, looking at
frisbee traces and tweaking Linux sysctls...

In at least the Linux 3.2 kernel on Ubuntu 12, setsockopt to set the socket
buffer size does not return an error if you try to set a value higher than
the kernel max. So we do an immediately following getsockopt to verify.

This will prevent the server from over-driving the send socket (leading to
re-requests of blocks from clients) for really high bandwidth values (i.e.,
with large burst sizes).

Sort them by the node_id the admins assigned, rather than by the
order they were added in.