=====Squid web proxy=====
  * Set up and document (especially document on the wiki how to set up), a web proxy on a VM (you can utilize vmserver03 or vmserver01-- I've turned off the other two for the time being as climate control is off so it is a little warm in there right now).
  * I am after regular caching (where web browsers would need to be specifically configured to utilize the proxy).
  * There is a "transparent" or "interception" proxy capability to squid (where no changes to clients would be needed), but ultimately that requires more firewall configuration and a loss of metric collection. I'm primarily interested in being able to accomplish the following:
  * disable direct web access to all machines on the network except for the proxy (clients would get a "you need to configure your proxy settings" type of page).
  * prevent netboot Debian installs from still going out to the internet for security (or even for people who forget to type in "mirror")... we could do some redirections at the proxy level so that package archive requests are redirected to mirror anyway.
  * web proxy access via user authentication (so we can pull up per-user reports on their web activity).
  * general web usage metrics in general (so I can show that X% of web accesses are going to facebook, omegle, etc.)
  * the ability to block a site (I'm not interested in permanently banning stuff, but sometimes it is convenient to block a distracting site for an hour or so).
  * investigate how best to roll out the proxy changes (so both new and existing users wouldn't necessarily have to set their browser settings-- perhaps just be prompted on their first use to enter their credentials to gain access to the proxy).
  * hopefully, authentication to the proxy can tap into LDAP in a somewhat easy way.

=====replicating multi-site web content=====

  * establish two or more VMs that can be hit up for content (dokuwiki, web pages, whatever).
  * document how to do this on the wiki
  * any changes that take place to one web host will be propagated to the others (so you can have a universal resource, and writing to the nearest source would still push updates to the others-- as "nearest source" would differ for different people in different locations).
  * in some ways, I'm more interested in replication than a full out load balancing using LVS or some such... I'd be content, in the end, with just configuring DNS to have an "info" name or something on each subnet.. I'm mainly after the automatic replication of web server content.
  * as such, any load balancing stuff might be neat to see in action, but if push comes to shove, replication first, load balancing second (I would imagine many replication methods are load balancers... but just in case they're not, there's my preference).
  * if possible: depending on which server is accessed, display a location-specific starting page for the wiki (ie accesses from the 10.80.3.x subnet when hitting the wiki would display a student.lab page, 10.80.2.x would do offbyone.lan, etc.)
=====migrate/upgrade an existing web server=====

  * web.offbyone.lan is our internal information store that has been in need of a significant upgrade for some time (web is NOT www, which was used for the class wikis).
  * I'd like it upgraded to a Debian Lenny VM, and existing content moved over
  * Additionally, it currently uses a MediaWiki wiki, I'd like to use Dokuwiki instead (to bring it more in line with existing environments, such as that on www)... so there may be some syntax retrofitting to get all content adequately moved over.

=====multi-master LDAP=====
  * setup three or more LDAP servers
  * document (on the wiki)
  * populate with some fake/test user data
  * configure LDAP servers to do multi-master replication amongst themselves
  * possible load balancing

The idea is to ultimately roll out more than just one LDAP server on each domain, so in the event of a failure (Server is down), the subnet doesn't have a seizure (clients would be configured to be aware of multiple LDAP servers-- or through a load balancer, just be moved over to an accessible LDAP server).

Additionally, it would be nice to enable updates to take place at the local LDAP server (for example a password change), and have those changes propagate to the other LDAP peers.

For now, concentrate your efforts on VMs in the student.lab network. As you need to do more testing, I can roll you a VM on some other subnets.

=====kerberos/LDAP authentication=====
  * set up a working LDAP/Kerberos configuration (LDAP servers, Kerberos servers-- could be on the same machines if need be)
  * document (on the wiki)
  * look into establishing kerberos authentication over web (so a user who logs in at a workstation in the LAIR wouldn't then need to log in to the wiki, or potentially even to Lab46-- because they'd already have a granted ticket from their initial log in).