A Hacker’s Vacation

[Head in the clouds]I took this week off work to enjoy a Hacker’s Vacation. That is, I’m planning to spend a lot of time hacking on my computer.

It’s more than that, actually. I desperately need some time to put my life back in order and catch up on things that I’ve been neglecting, such as housework, email, this website, hard drive spring cleaning, my Tchou Tchou’s website, the Swing website, a new server, and various little projects I have going on. Slowly, I’m getting parts of it all done. I’ll have to carry on some of the tasks later, but at least this week will give me a good foundation to work with.

The biggest thing I want to hack on is my brain. As I mentioned above, I’ve got a new server and I need to spend some time learning how it works. I’m intimately familiar with FreeBSD, but since it’s a virtual hosting solution, I’m constrained at this point to use Debian GNU/Linux on the new server. Since I’ve been using Ubuntu (which is based on Debian) on my desktop for over a year, it is fairly easy to manage. But there are lots of server-related configurations and tasks that I need to nail down for good security and management.

For general Linux information goodness, I’m following a set of tutorials from the IBM Developer Network entitled the Linux Professional Institute (LPI) exam prep, described as a “series of tutorials to help you learn Linux fundamentals and prepare for system administrator certification”. I’m not intending to write the exams—just learn the material. I’m finding that the tutorials give very good background information, covering things in enough detail to explain the process. I can then, of course, delve into the man pages and other documentation to learn more.

I’m enjoying it so far.

Ubuntu + Python + BitTorrent trouble

I’m wondering if anyone else has experienced trouble with the Python that comes installed with Ubuntu when trying to use the official Python BitTorrent client. (Note that Ubuntu comes with a Python BitTorrent client, but it’s completely different than the official one. Seems like a rewrite. I don’t know its origin.) Anyway, the official btdownloadcurses.py eventually hits some error that screws up the screen drawing, and btlaunchmany.py eventually stops working and begins sucking up 100% of the CPU.

I’ve seen lots of discussion regarding different clients and different OSes with regard to the 100% CPU usage. But I don’t think this is related. Now my intuition told me that the fault lies with Ubuntu’s Python installation. The above problems occur under Hoary and Breezy, and I’m using Python 2.4.2 of the Ubuntu base installation and BitTorrent 4.0.4 downloaded from the BitTorrent website.

So in an experiment last night, I grabbed the sources from www.python.org and compiled my own Python 2.4.2 from source. So far, the official BitTorrent client hasn’t cracked or croaked when running under this Python. So there is something weird about Ubuntu’s Python installation. I wonder what’s different about it.

Update: Well, I spoke too soon. After two days of running soundly, the client gave up the ghost just like before. So, now what? I guess I’ll go back to FreeBSD.

Server Madness Madness

In my last post, I ranted on about the hardware troubles that I was having with my server. After writing the entry, Bruce and I had a long keyboard chat about our situation and how we were going to proceed with the network and the machines we had available to us. It was a productive meeting. But here’s the kicker: right after we finished chatting, Bruce’s desktop kicked the proverbial bucket. Man is it a bad month for him and me, technologically speaking! He figures it’s the 1 GB RAM chip that went bad. Unfortunately, there’s no money to get a new one.

Bruce connected a keyboard and monitor to the server so he could use it as a life raft to contact me. As we chatted this second time, he tried to get the old server back together. Fortunately, he succeeded, despite having been unsuccessful with that hardware configuration a few days before. So the new server became Bruce’s new desktop and we brought the old server out of its two-week retirement. So server-wise, everything is back to the way it was before I began changing it all around.

Whew! It was a heck of a ride. But for now, my experiments are dead in the water and my hopes for some really cool applications for the Swing Beijing! website have been dashed. I await further inspiration while hoping to avoid any more meltdowns.

Server Madness

I am a FreeBSD god. I can administrate my way in and out and upside down a FreeBSD box like mad, and do good work, too. Computers used to frustrate me endlessly until one day in 2000 I installed FreeBSD 4.0 on an unwanted machine and all my problems magically disappeared. It just made sense. And it worked. And the documentation was so complete that I hardly ever had to search the web for how to do stuff. So the unwanted machine became my desktop, and eventually I set up another box as a server for my (then) website, and as a firewall/router for my friend Bruce. That server has been serving us faithfully for many years, a Pentium I, 100 MHz machine with RAM varying from 32 MB to 80 MB.

Over the last month, however, I started planning for some future projects and my experiments showed that “the little server that could” just “couldn’t” any more. I needed more raw CPU power. So I replaced the server with my Mom’s old Celeron 500 MHz machine, and that’s where my trouble began. Twice, the machine locked up for no reason when reading in from swap during my experiments. It was running the latest FreeBSD 5.4. So I wiped it clean and reinstalled FreeBSD 4.11, the latest stable version from the 4 branch, thinking that somehow the problem was with the 5 branch of FreeBSD. But this morning, doing a simple cp -Rp /oldroot /usr/, it locked up again.

Damn, this is annoying.

I’m starting to suspect the new hard drive, or its interaction with the hardware. And this is where my power as a FreeBSD god fails. I can’t do nothing about how well the system runs if it’s running on flaky hardware. And so I’m frustrated, so frustrated, yet again. I have a few ideas on how to proceed and resolve this whole mess, but for the moment, I’m just waiting on Bruce’s assessment of the situation. Blogging this is part of my therapy to step back and perhaps feel better about the situation. How’s it going so far?

I do admit to one fundamental mistake: running experiments on a production system, or more accurately, replacing a tried-and-true production system with an experimental system. I could have (and should have) run both systems at the same time, ensuring the stability of the new system before retiring the old one. But the one thing that stood in my way was the number of ports in Bruce’s hardware router. I should have just told him to go and buy a larger hub. Oh well, back to work…

DenyHosts on FreeBSD

On a tip from the news site RootPrompt, I discovered a small security utility called DenyHosts which is for Linux systems to help thwart ssh server attacks. It examines the sshd logs and looks for multiple failed login attempts. It then collects the IP addresses of the offending hosts and writes them out to /etc/hosts.deny so that these hosts will be blocked from further access to the machine.

Since the server in question is running FreeBSD, which uses a combined allow/deny syntax in hosts.allow and doesn’t use hosts.deny, I had to modify the DenyHosts script script slightly to get it to work in the FreeBSD context. Basically, I configured DenyHosts to write to a dummy hosts.deny file and then wrapped it in a cron(8) script to concatenate this dummy file with a hosts.allow.template file. Thus hosts.allow is dynamically generated with the dynamic deny rules first and the static allow rules last.

It seems to be working so far. 🙂

Update from the comments: FreeBSD is now supported in the latest version of DenyHosts.

Dodged a howitzer this time

We were lucky. Very lucky. Saturday morning (for me), I logged into madphilosopher.ca from my home in Beijing. Immediately, my friend Bruce, who was also logged in at the time, sent me a message saying that we had a serious problem: “The heads are banging.” I had to ask him what he meant by heads. I thought that perhaps he meant potheads were attacking the computer. Then without warning me, he rebooted the machine, which had the effect of booting me off. When I logged back in five minutes later, I was able to ask him what the problem was. The hard drive was making noise, a sign that it was about to die. Oh! So that’s what he meant by “the heads were banging.” (A little context goes a long way, in my book.)

The machine, madphilosopher.ca, is an old Pentium 100 running FreeBSD 4-STABLE. It’s been in the service of its current role for about three years now. Bruce added a second hard drive a few months ago to provide space for backup and archiving purposes. So it wasn’t clear in the present emergency whether the new or the old hard drive was about to die. (I suppose if he had a stethoscope handy, he could have determined the source of the noise.) Losing the old hard drive would have resulted in much downtime since it is the system drive. Losing the new drive would have wiped out backups, but the system could have carried on without it.

We make regular, automated backups of the system, but having fresh backups is prefered when you might have to rebuild the system. So Bruce and I spent the next two hours creating backups of various system and user files and transfering them off the machine before its impending doom. The noise kept coming and going, and that kept us even further in suspense.

We were communicating using a chat window running on the machine, but we agreed to meet on Yahoo chat in case the system went down and cut off our line of communication. That never happened. So after the backing up was done, Bruce went to watch the news on TV and I needed to leave the house and get on with my Saturday. I checked in with him much later to see what had happened with the hard drives. He was supposed to power down the machine and pull it apart to find the source of the noise. Well, it turned out not to be the hard drives at all. It was the CPU cooling fan dying a slow death. In an email, he said to me, “That was the closest I’ve come to witnessing a hard drive dying without it actually dying. We dodged a howitzer this time!”