This page is live on our site right now, probably not linked to from anywhere.

I only have one thing to say…

Highly sketchy, publicly accessible server configuration.

Diversity in action.

This is the new location of our servers. As long as they don’t get eaten by the gigantic stack of batteries next to them, we should be pretty stable. It’s a little scary when you reach to the back and realize that 30% of your body is leaning heavily on exposed battery terminals

drool. From top to bottom: Packeteer, Firewall A, Firewall B, and our multi-million dollar router.

The system is going down for system halt NOW!
Connection to heimdall.restek.wwu.edu closed by remote host.
Connection to heimdall.restek.wwu.edu closed.

Heimdall has faithfully chugged along for years collecting bandwidth stats. As our most underpowered server, it has recieved the fanciest home in the basement of Bond Hall. Now that the filters can collect all bandwidth stats and run our IDS, we have no use for this lowly pizza box.

Next time I’m down there I’ll take some pictures to post up here.

sudo su - SOMEUSER

should work great. After typing in my password, I see the following message:

         *** System shutdown message from root ***
 system going down in 60 seconds

I start freaking out, and eventually realize that I should reboot the dang server before it is shutdown. This is one server that I don’t want powered off while locked deep in some telecom room on campus. So it reboots just fine, the CARP failover works great, all is well. I kind of forgot about this mystery until today, when I realized what had happened:

mike# fortune

        *** System shutdown message from root ***
system going down in 60 seconds

IT’S A FREAKING FORTUNE MESSAGE. WORST JOKE EVER. NOT FUNNY AT ALL.

So back in August Nick noticed a bug in the bandwidth graphs when displaying weekly data. I was bored in class today, and scribbled down some notes about what interval to display ticks at. It was a pretty easy fix, once I had all intervals calculated.

New weekly graph

I think I’m doing an excellent job of clogging up the planet with images.

Also, comforting to hear than Nick is scared.

Guess when the limits were removed?

We are now pushing an impressive amount of data through the proxy. Just another remind that we need to push for the rate limit changes. At least once the madness of opening has settled down.

Nick and Luke explaining the registration process and proxy settings

A bunch of the staff sat in the corner of the room hacking away on various things on our laptops

The staff seems to be surviving the ordeal of training fairly well.

Michael (my gunn) and Lawrence snapping photos

All this week we have been working like crazy to get the filters ready. Thanks to the swifty support of telecom we have make excellent progress. The filters are running in Bond Hall, with live management IPs. Mr. Router Man is ready to give us the live IP addresses that the filters will need for production. We are going to make a try at getting them in the networking loop this weekend. Nick and I had a very nice experience testing the filters on Thursday. After they were installed we were able to send data through them on the test network. You get a very odd feeling when you are plugging your laptop directly into ports on a brand new Cisco router. Redundancy seems to work nicely, but we were experiencing up to 3 second delays for the failover to happen. Reading the ifconfig man page specifies that the default timing for CARP notifications is 1 second. The algorithm for detecting a failure of the master interface is 3 times the advbase + advskew settings. So 3 seconds would make sense. I’m pretty sure we can tune the notifications to be quicker.

We found out today what the bandwidth will be for the 2004-2005 school year. I guess it’s still supposed to be a surprise, at least until we verify that the link is working at that speed. This little detail we learned today is basically the icing on the cake. After preparing all the server and networks tricks we can to minimize viruses and other “junk traffic” we now find out that we will have a comfortable amount of bandwidth.

This should be a great year for Internet in the residence halls. I can’t wait to sit back and watch all of our tools beat the network traffic into submission.

This finally solves the race condition when the next available IP in a subnet is picked. There is a brief period before the IP is actually recorded as registered, and other students could grab the same IP to register. The new holding table method insures that only one IP is picked and registered at the same time.


1.4 +5 -3 styx/frontend/admin/links.php
- condense something
1.5 +1 -1 styx/frontend/admin/links.php
- fix that one time that I totally <BAD WORD> up quotes in PHP
1.10 +7 -1 shared/restek.css
- CSS for form in sidebar
1.11 +5 -1 shared/restek.css
- OMG style the form more
1.6 +6 -0 styx/frontend/admin/index.php
- add in box for getting an IPs graph
1.13 +2 -1 styx/frontend/admin/graph.php
- fix infinite loop when there is no data in the DB for that time period
1.1 +11 -0 sluice/log.php (new)
- add a php script to ACTUALLY <BAD WORD> MADE THE STUPID DB INSERT.
1.91 +1 -3 shared/sluice/Sluice.pm
- instead of making a simple SQL insert, call a different script, in a different programming language to make the SQL insert.
1.4 +12 -9 styx/frontend/admin/sluice/config.php
- use db clas s
1.2 +0 -11 sluice/log.php (dead)
- move file
1.1 +11 -0 sluice/cronscripts/log.php (new)
- move file
1.29 +5 -5 shared/styx/limitHistory.php
- use seperate config db handle
1.10 +1 -1 styx/frontend/admin/sluice/graph.php
1.39 +3 -2 styx/frontend/admin/sluice/numLimited.php
- fix, by using seperate config db handles
1.9 +2 -2 CVSROOT/cfg_local.pm
1.8 +2 -1 CVSROOT/rcstemplate
- don't show tasktrack stuff
1.68 +75 -0 shared/Ipreg.php
- new holding code
1.28 +2 -31 ipreg/hallserver/frontend/register.php
- OMG redo pick IPs. We are now awesome.
1.69 +2 -9 shared/Ipreg.php
- correct type detection in register();
1.70 +1 -1 shared/Ipreg.php
- )) is not a line ending ); is
1.18 +5 -0 shared/RegException.php
- add dummy getPidnum function
1.19 +1 -1 shared/RegException.php
- exceptions are pidnum 1
1.71 +1 -1 shared/Ipreg.php
- setName(), not checkName()
1.72 +18 -1 shared/Ipreg.php
- use correct type names
1.27 +17 -10 ipreg/cronscripts/makeDhcpConfig.php
- perform holding
- sort by ip
- don't check for blank mac address
1.30 +1 -1 ipreg/hallserver/frontend/register.php
- fix Student registering


On the left side of the firewalls is one subnet, 10.4.0.0/24. On the right side is another, 10.5.0.0/24. These will be real live IPs when we are in bond hall. The routers serve as a gateway on each end. Each firewall has an IP on each of the 2 subnets here. So firewall A has an interface with the IP 10.4.0.17 and one with 10.5.0.17. These IP’s don’t serve much purpose. Then each firewall is configured with the virtual IP of the gateway for each subnet. The gateway of the 10.4.0.0/24 network is 10.4.0.12, etc. The firewalls decide who will act as the master for the gateway IP using the CARP protocol from OpenBSD. This page has good examples of the power of CARP.