As part of Club Moz at Seneca I was involved with running our Firefox 2.0 Launch Party after the FSOSS last night. After some bribery with stickers and t-shirts (thanks Asa!) and the promises of pop and chips we managed to drag quite a few people in. There was music, chit-chat, and some pictures taken. El Presidente, gave a quick speech thanking everyone for showing up. Given the short amount of time we had to plan this event I think it went very well. There's a lot we can do to make the next ones better and I've gotten some ideas from reading other blogs. So, you ain't seen nothing yet!
So thanks to everyone that helped out: Tom, Liz, Vanessa, Phil, Moe, Dave, Asa, Andrei, Seneca Student Federation, and of course John, for giving us the Club Moz idea in the first place.
Thank you to Mike Shaver and David Humphrey for telling me what a success the party was -- it was good to hear someone else thought so!
Saturday, October 28, 2006
Tuesday, October 17, 2006
Update: Wireless Connection
So it seems I may have been to hasty in blaming the schols network for my wireless network issues. I started using wireless at home to see if the problem would happen there -- and it did. There's nothing more annoying than watching a movie and all of a sudden having it stop playing. Not being able to slack off at school is one thing, but this is a whole other issue.
I grep'ed through my logs and found all sorts of this stuff:
The times on that correspond *exactly* to when I was booted offline. 'dhclient' is the default dhcp client in Ubuntu Dapper. However I prefer 'pump', it's something I always install after a re-format. It seems that my manually usage of pump doesn't work so well with Ubuntu's automagic dhcp stuff'n'crap. I guess the two daemons fight for who will hold control over the lease -- I'm not sure. In any case, after doing an apt-get remove dhcp3-client the problem was solved! No more wireless issues, yey!
Now...if I could only get something to automatically login to bluesocket for me I would be even happier
I grep'ed through my logs and found all sorts of this stuff:
Oct 15 00:00:37 wesley dhclient: DHCPREQUEST on eth1 to 192.168.0.1 port 67
Oct 15 00:00:38 wesley dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
Oct 15 00:00:38 wesley dhclient: send_packet: Network is down
Oct 15 00:00:49 wesley dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Oct 15 00:00:49 wesley dhclient: send_packet: Network is down
Oct 15 00:00:52 wesley dhclient: DHCPREQUEST on eth1 to 192.168.0.1 port 67
Oct 15 00:01:01 wesley dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
Oct 15 00:01:01 wesley dhclient: send_packet: Network is down
Oct 15 00:01:04 wesley dhclient: DHCPREQUEST on eth1 to 192.168.0.1 port 67
Oct 15 00:01:19 wesley dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
Oct 15 00:01:19 wesley dhclient: send_packet: Network is down
Oct 15 00:01:22 wesley dhclient: DHCPREQUEST on eth1 to 192.168.0.1 port 67
Oct 15 00:01:30 wesley dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2
Oct 15 00:01:30 wesley dhclient: send_packet: Network is down
Oct 15 00:01:30 wesley dhclient: DHCPREQUEST on eth1 to 192.168.0.1 port 67
The times on that correspond *exactly* to when I was booted offline. 'dhclient' is the default dhcp client in Ubuntu Dapper. However I prefer 'pump', it's something I always install after a re-format. It seems that my manually usage of pump doesn't work so well with Ubuntu's automagic dhcp stuff'n'crap. I guess the two daemons fight for who will hold control over the lease -- I'm not sure. In any case, after doing an apt-get remove dhcp3-client the problem was solved! No more wireless issues, yey!
Now...if I could only get something to automatically login to bluesocket for me I would be even happier
Thursday, October 12, 2006
The little connection that couldn't.
The wireless internet at my school sucks. Since the start of the Fall semester is has been barely usable. My connection is dropped every 2 to 10 minutes. I've upgraded the drivers for my wireless card -- didn't help at all. It happens all over the damn school but not *all* the time.
It's hard to say exactly what it is. Between the summer and fall semesters I upgraded to Ubuntu Dapper, but I don't think that would cause these problems. Especially since I'm running a custom kernel and the latest drivers. Tom has similar issues. I think it's just the access points being overloaded with traffic.
It's really frustrating though, and defeats the purpose of having wireless access.
It's hard to say exactly what it is. Between the summer and fall semesters I upgraded to Ubuntu Dapper, but I don't think that would cause these problems. Especially since I'm running a custom kernel and the latest drivers. Tom has similar issues. I think it's just the access points being overloaded with traffic.
It's really frustrating though, and defeats the purpose of having wireless access.
New Buildbot Patch
I've submitted my latest patch for the Buildbot. This one adds support for per-build comments akin to the Tinderbox feature.
This patch was a lot tougher than the previous ones. I went through implementation of a couple different ideas before I found a way that worked and wasn't an ugly hack. Right before creating the final diff I ended up not including my "user javascript" support. When I look at the patch now it has absolutely no code from my first attempt in it. I've read that this is often the case but I've never experienced it until now. Working on the Buildbot has really proved to me the need for some design before implementation. During my first two revisions of this patch I *did* do some design but I skimped out after getting the general idea and ended up tossing all of that code out.
Working with C++ for the past 8 months really turned me off of OOP, or so I thought. Working with the Buildbot has been a good experience for me. It's a mid-sized project, very highly designed, and very well implemented (at least from what I can tell). It has shown me that OOP doesn't have to suck, and that not all OOP languages suck.
This patch was a lot tougher than the previous ones. I went through implementation of a couple different ideas before I found a way that worked and wasn't an ugly hack. Right before creating the final diff I ended up not including my "user javascript" support. When I look at the patch now it has absolutely no code from my first attempt in it. I've read that this is often the case but I've never experienced it until now. Working on the Buildbot has really proved to me the need for some design before implementation. During my first two revisions of this patch I *did* do some design but I skimped out after getting the general idea and ended up tossing all of that code out.
Working with C++ for the past 8 months really turned me off of OOP, or so I thought. Working with the Buildbot has been a good experience for me. It's a mid-sized project, very highly designed, and very well implemented (at least from what I can tell). It has shown me that OOP doesn't have to suck, and that not all OOP languages suck.
Friday, October 06, 2006
On unit testing
I've been hacking on the Buildbot for a month or so now. I've released two patches for it, a Bonsai Poller and a Tinderbox Mail Notifier. I noticed recently that Buildbot has a lot of test cases in it's tree. I've heard the phrases "unit test" and "test case" before but I didn't know what they were until today. My patches are more or less complete and have been tested but I still think it would be nice to have test cases for them. The buildbot tree will change, bonsai and tinderbox may change, and this should be a relatively simple way to get me introduced to the concept of unit testing.
I spent an hour this afternoon reading Buildbot test cases and other unit testing documents. The Buildbot uses Twisted's unit testing framework for it's tests. I found the docs for those here. This went into the specifics of writing test cases with Twisted but after reading it I still didn't feel comfortable with the concept. There was a link to Dive Into Python on the Twisted page. This is an excellent read for anyone new to unit testing. It goes from no source to test case to working code.
I've done much of what is involved in making a test case without actually making a test case. One of the key things I like about unit testing is that it defines your API. I was chatting about this in #seneca and shaver said "that also has the nice effect of keeping you honest about what you really _need_". This is a very good thing for someone like me! I went through 3 or 4 revisions of my BonsaiPoller classes before coming to the final version. I don't think this is necessarily a bad thing but I know this happened because I didn't think enough about what it should look like before attempting to implement it. Before writing the final revision I actually wrote a script that defined how I was going to use the class. Looking back on it, that was a rudimentary test case. It wasn't well organized, it wasn't testing small pieces at a time, but from a design standpoint it accomplished the same thing.
I see lots of similarities to unit testing and things I've encountered in my classes. We often get "test mains" from professors to test our assignments before handing them in. These are often in the form of small tests to every part of our classes. In my systems course we just finished doing Scenarios. To me, a scenario seems like a test case for use case description. There is obvious differences but while a test case tests the validity of code, a scenario tests the validity of a use case description.
Unit testing is very interesting! I plan to adopt it whenever I can. I expect that I will go from idea to working code quicker if I do it right.
I spent an hour this afternoon reading Buildbot test cases and other unit testing documents. The Buildbot uses Twisted's unit testing framework for it's tests. I found the docs for those here. This went into the specifics of writing test cases with Twisted but after reading it I still didn't feel comfortable with the concept. There was a link to Dive Into Python on the Twisted page. This is an excellent read for anyone new to unit testing. It goes from no source to test case to working code.
I've done much of what is involved in making a test case without actually making a test case. One of the key things I like about unit testing is that it defines your API. I was chatting about this in #seneca and shaver said "that also has the nice effect of keeping you honest about what you really _need_". This is a very good thing for someone like me! I went through 3 or 4 revisions of my BonsaiPoller classes before coming to the final version. I don't think this is necessarily a bad thing but I know this happened because I didn't think enough about what it should look like before attempting to implement it. Before writing the final revision I actually wrote a script that defined how I was going to use the class. Looking back on it, that was a rudimentary test case. It wasn't well organized, it wasn't testing small pieces at a time, but from a design standpoint it accomplished the same thing.
I see lots of similarities to unit testing and things I've encountered in my classes. We often get "test mains" from professors to test our assignments before handing them in. These are often in the form of small tests to every part of our classes. In my systems course we just finished doing Scenarios. To me, a scenario seems like a test case for use case description. There is obvious differences but while a test case tests the validity of code, a scenario tests the validity of a use case description.
Unit testing is very interesting! I plan to adopt it whenever I can. I expect that I will go from idea to working code quicker if I do it right.
Thursday, October 05, 2006
More fun.
I just spent hours and hours trying to figure out why my RDP client couldn't connect to a Windows 2003 server that I setup. It's behind a NAT and port forwarded so maybe that was the problem?
Nope.
The encryption level was set too high. When I created the RDP service I must have used the 'FIPS Compliant' encryption level, which isn't supported by my client. Changing it down to "low" fixed it.
Nope.
The encryption level was set too high. When I created the RDP service I must have used the 'FIPS Compliant' encryption level, which isn't supported by my client. Changing it down to "low" fixed it.
Wednesday, October 04, 2006
VMware, oh VMware.
Due to certain circumstances I've been attempting to forward ports from a NATed machine to a guest VM on that machine. What a hellacious experience.
The setup is as follows:
Normally I would use bridged mode with VMware but the DHCP server on our subnet will only hand out one IP per port, as far as I can tell. So NAT it is! This means that the VM guest OS is behind 2 levels of NAT, how ugly.
The goal here is to give ssh access to the VM guest. The VM host has a few ports forwarded to it, 5900 for example. This is what I'd like to do:
Very ugly, but that in and of itself should work. Should work, but it didn't. I was at a loss at this point. Luckily, I have a friend who works debugging network issues. We obtained network traces (dumps of all packets going through an interface) from the VM guest and VM host, and took a look at them. The first thing he noticed was a fishy MAC address. I checked the MAC of the VM host's eth0 and vmnet8 AND the MAC of the VM guest's eth0. Neither of them matched.
We tried again, but this time checked the ARP cache. AHA! There's the mysterious MAC address. It belongs to....192.168.87.2? What the hell is that? The VM host is 192.168.87.1 and the VM guest is 192.168.87.5. It's pingable, so it has to be _somewhere_. My buddy suggested checking the default gateway of the VM guest. Voila! 192.168.87.2.
The best we can determine VMware has some sort of internal router when using NAT mode. It's definently not accessible or configurable.
Nonetheless, a workaround was proposed. Simply changing the gateway from 192.168.87.2 (the internal VMware thingy) to 192.168.87.1 (the VM host) will get rid of that weird MAC. I did that.....and I could ssh to the VM guest! Hooray! But....I can't intiate any connections from the guest.
I originally thought that the NAT was done by the VM host. Now it seems more likely that it is done by the internal, non-configurable VMware NIC. If I actually setup a NAT between 10.5.1.0/24 and 192.168.87.0/24 I *think* it would work...but that's overkill for a temporary solution.
I decided to switch back to bridged mode and set the VM guest IP statically. This works fine for getting on the network and the Internet. I should be able to get the Powers in Charge to forward ports to them.
So what did I learn from all of this?
The setup is as follows:
Router <-> VM host <-> VM guest
142.x.x.x 10.5.1.10 192.168.87.5
192.168.87.1
Normally I would use bridged mode with VMware but the DHCP server on our subnet will only hand out one IP per port, as far as I can tell. So NAT it is! This means that the VM guest OS is behind 2 levels of NAT, how ugly.
The goal here is to give ssh access to the VM guest. The VM host has a few ports forwarded to it, 5900 for example. This is what I'd like to do:
Router <-> VM host <-> VM guest
142.x.x.x:10900 -> 10.5.1.10:5900 -> 192.168.87.5:22
Very ugly, but that in and of itself should work. Should work, but it didn't. I was at a loss at this point. Luckily, I have a friend who works debugging network issues. We obtained network traces (dumps of all packets going through an interface) from the VM guest and VM host, and took a look at them. The first thing he noticed was a fishy MAC address. I checked the MAC of the VM host's eth0 and vmnet8 AND the MAC of the VM guest's eth0. Neither of them matched.
We tried again, but this time checked the ARP cache. AHA! There's the mysterious MAC address. It belongs to....192.168.87.2? What the hell is that? The VM host is 192.168.87.1 and the VM guest is 192.168.87.5. It's pingable, so it has to be _somewhere_. My buddy suggested checking the default gateway of the VM guest. Voila! 192.168.87.2.
The best we can determine VMware has some sort of internal router when using NAT mode. It's definently not accessible or configurable.
Nonetheless, a workaround was proposed. Simply changing the gateway from 192.168.87.2 (the internal VMware thingy) to 192.168.87.1 (the VM host) will get rid of that weird MAC. I did that.....and I could ssh to the VM guest! Hooray! But....I can't intiate any connections from the guest.
I originally thought that the NAT was done by the VM host. Now it seems more likely that it is done by the internal, non-configurable VMware NIC. If I actually setup a NAT between 10.5.1.0/24 and 192.168.87.0/24 I *think* it would work...but that's overkill for a temporary solution.
I decided to switch back to bridged mode and set the VM guest IP statically. This works fine for getting on the network and the Internet. I should be able to get the Powers in Charge to forward ports to them.
So what did I learn from all of this?
- Network traces are very useful.
- VMware NAT mode should only be used as a LAST resort.
- Politics suck.
Monday, October 02, 2006
Subscribe to:
Posts (Atom)