I’ve uploaded pictures taken by CalLUG (UC Berkeley GNU/Linux Users Group) staff during the Richard M. Stallman and Chris DiBona speeches. Please click on either of the following thumbnails to browse the complete album.
Richard M. Stallman Speech
Chris DiBona Speech
Now that I’ve survived my first wave of midterms, I plan on devoting more time to my extracurricular activities.
I’ve noticed that my daily del.icio.us script for Wordpress is broken, so I’ll be updating it to work again, and I’ll be finally addressing the nagging issue of time sync in that script. I also just finished setting up a Xen server for the System Administration for the Web class, so I’ll be sharing my experiences building a Debian Xen server via a comprehensive Xen 2.0.7 HOWTO — one cannot begin to describe the lack of documentation for Xen. Lastly, I’ll be updating some projects that are currently off-limits to the public. I’ll be releasing more information about them when they reach a usable state.
The UC Berkeley Linux Users Group will be hosting a speech by Chris DiBona, Open Source Program Manager for Google and a former editor of Slashdot, on October 17 from 6-8 PM at 306 Soda. As with all CalLUG events, the speech is open to the public and there will be no cost to attend.
If you’re interested in Linux and learning about the latest Google technology, be sure to come!
I think the time gap between this post and the last post is the longest such gap this blog has ever seen.
Many things have occurred since the last post, and most of them have been keeping me very busy. Here’s some of the important stuff:
I moved back into the dorms. This will be the first year where I haven’t lived in Bowles Hall and where I’ve had a roommate. While I have nothing against my current living conditions, I still wish I was able to return to Bowles Hall — I really miss the atmosphere and short walk to classes. As an aside, I was recently quoted in the San Francisco Chronicle about the changes in policy regarding my former dormitory.
My third year at UC Berkeley started, and I’m as busy as ever. I’m taking five upper-division courses, and they leave me with very little free time. I’m feeling a lot of pressure to become more efficient with my time. We’ll see how that goes…
Along with my friends Ryan and Dima, I’m currently trying to bring back the Berkeley GNU/Linux Users Group. This week, we held a speech by Richard M. Stallman, who turned out to be pretty interesting. Pictures are posted here.
I’m acting as a co-teacher/teaching assistant for CS 198: System Administration for the Web. It’s an interesting and educational experience to teach people. I’m having fun, and I think it’s a great way to develop my skills at presenting information.
I’ve also had some computer problems, and, as I type this post, I’m attempting to recover data from a broken backup. The one lesson that I’ll never forget from this experience is to always test my backups before going ahead with a possibly destructive task. Though nothing vital was lost, the information I did lose was of considerable value.
I wasn’t able to sleep, so I wrote this Perl script to backup a directory and mail yourself a copy. Change the variables in CAPS to suit your needs. It’s best to run this script as a cronjob.
Download a plaintext copy here.
Updated 5/8/2005: I’ve modified the code to use the File::Find library instead of a glob. My previous iteration of the code ignored hidden files (easily fixable by adding a second glob) and sub-directories. This new version fixes those two issues.
#!/usr/bin/perl
# This script creates an in-memory gzipped tar archive of the $BACKUP_DIR
# and emails the archive to an email account.
# Copyright Stephen Le
# Last Modified: May 8, 2005
# http://stephen.evilcoder.com
use MIME::Lite;
use Archive::Tar;
use Compress::Zlib;
use File::Find;
use strict;
my $SENDER = 'sender@domain.com';
my $RECIPIENT = 'recipient@domain.com';
my $BACKUP_DIR = '/directory/to/backup';
my $tar = Archive::Tar->new;
find(\&wanted, $BACKUP_DIR);
sub wanted {
$tar->add_files($File::Find::name);
}
my $msg = MIME::Lite->new(
From => $SENDER,
To => $RECIPIENT,
Subject => "Backup of " . $BACKUP_DIR . " at " . localtime,
Type => "multipart/mixed",
);
$msg->attach(
'Type' => 'application/octet-stream',
'Encoding' => 'base64',
'Filename' => "backup.tar.gz",
'Data' => Compress::Zlib::memGzip( $tar->write )
);
$msg->send;
I’ve just finished some intensive tweaking of the Cold Ray Hosting servers. I was able to reduce the memory used by Apache, our web daemon, and MySQL, our database daemon. By reducing the memory used by each daemon, I was able to release memory to other active processes.
The immediate benefit of my tweaks is a more responsive server, as evidenced by the faster loading of this blog. Furthermore, I’m confident that the optimizations will result in greater server stability and uptime.
Now that all my midterms are over, I’ve been able to dedicate some time to working on my web hosting company, coldray.com. Our system has been up for a few months, and a user-friendly control panel is now undergoing testing. This weekend, I’ve added one more component to our web hosting offerings: self-service support in the form of a wiki.
coldray.com’s wiki is based upon MediaWiki, the same wiki software that powers the venerable Wikipedia. Although MediaWiki doesn’t provide all the features I would like, I chose it because of its popularity and active development. Those two factors distinguish it from the other open-source wiki programs — I can rest assured that security holes will be discovered and patched in a timely matter, and more features implemented as the number of users and their feature requests increases.
So far, I’ve populated the wiki with some basic information regarding the Control Panel, how to create and delete email accounts, FTP accounts, subdomains, and MySQL databases.
Registration is currently required to edit, and only authorized users are allowed to register. I’m planning to relax these restrictions once I understand MediaWiki security better.
I’ve created a new PGP key to replace my currently expired key, and I’ve attached the public key block to this message:
After upgrading my Linode to Linux kernel 2.6.9 for the file-system access control lists, my bind 9.2.4 DNS server has become very unstable. The daemon will run perfectly for a few hours, but will suddenly begin consuming all the CPU. The strange thing is that the process’s memory usage remains stable and none of the other bind child processes seem to be affected. My Linode does stop responding to DNS requests, though, so I have to forcibly kill the server processes and restart the daemon.
I’ve tried upgrading to bind 9.3.0 to no avail, and running bind in the highest debug mode has yielded very little information. According to the logs I produced over a three-day debugging period, the server’s failure is initiated by a normal DNS request. My best guess is that loading uncached DNS entries into memory is killing bind, but I’m not sure. To make matters worse, bind is refusing to let me strace it.
Help?
UPDATE - 12/14/2004 - Well, after upgrading to a new revision of kernel 2.6.9 and disabling some of the filtering processes on the server, my bind processes no longer go crazy. Although I still don’t know for sure what caused the problem, I suspect that bind doesn’t like being paged.
Linode uses a custom I/O token distribution mechanism which rate-limits the amount of I/O a single account can use in order to prevent a DOS attack on other clients on the same server. However, such a mechanism really hurts Linodes that heavily swap. With my memory-intensive filtering processes nearly always active, my Linode’s kernel was forced to swap the usually sleeping bind process. Whenever a DNS request was sent to my server, the kernel had to pull the bind process back into memory. Unfortunately, my Linode was usually low on I/O tokens at that precise moment, resulting in a troubling situation: the kernel couldn’t page in the process. I’m pretty sure this is what caused my problems.
During the weekends, when I have some free time, I’ve been (besides studying and sleeping):
Developing my ISP - pluto.betanegative.com went active last week (since renamed to mars.coldray.com). We’re currently hosted at ThePlanet with a modest amount of disk space and plenty of transfer. Since I’ve been busy with classes, I’ve only been able to configure Apache and some basic internal services. If time permits, I’ll be able to setup Postfix and get some spiffy webmail going this weekend. Hopefully.
Making Beer - That’s right, I’m actually using my Berkeley chemistry education. If you saw two guys carrying a large plastic bucket and a glass carboy around Berkeley this weekend, that was my friend Kevin and me. Although we can legally produce beer, we can’t legally drink it. Go figure.
Spreading OSS on the Berkeley DC Hub - If you’re a Berkeley student living in the dorms, you definitely want to check this out. It’s an incredibly fast private Berkeley P2P network hosted by my friend Mark that doesn’t count towards the bandwidth cap.