Wednesday, September 16, 2009

Got distcc(d) working!

I finally have distcc and distccd working, so now my ancient PowerPC iMac actually has all its code compiled by a semi-modern dual-core AMD machine. Woohoo!

Most of this was Gentoo magic that worked right out of the box, at least for portage. I still have not been able to prove to myself that I can actually use distcc manually as well. Of course that's not nearly as important... :-D

Next I have to try pump mode, and then it's off to setting up the old SPARC box I have lying around, also with distcc most likely. (It's equally straightforward to generate another cross-compiler using Gentoo's crossdev script. Sweet.)

Monday, September 7, 2009

I <3 LVM2

So when I installed Debian on my MSI Wind Netbook the other day, I was asked whether I wanted to have encrypted LVM2 volumes. I said yes, and I am already glad I did today: resizing works! :-D

Debian decided to give me a 4GB / and a 138GB /home which was a little unbalanced since I needed to install a lot of stuff. Also it made the swap space 2.3GB instead of the 4GB I would have liked. I was really bummed out for a few minutes until I remembered the LVM2 stuff.

So I went ahead and used resize2fs to make /home smaller, then lvreduce to make the volume for /home smaller, then lvextend to extend the swap space and a new mkswap on it, and finally lvextend to make / 16GB and resize2fs to expand the file system as well. And it all worked. Amazing! :-D

Makes me wish I had done an LVM2 install on my desktop at home too, but sadly I didn't feel comfortable enough with it back then. I am already using it on the gaming lab server, but I never had a reason to resize anything on there yet. Good to know that it'll work if I ever need to. I <3 LVM2! :-D

DenyHosts on Gentoo

When I set up a server, I like to move the port for sshd away from 22 to some high location, say 32767. At JHU, however, high ports are blocked by the good folks in IT. So machines I host on campus actually get attacked a good deal more than machines I host off campus where I control the firewall. Talk about "security" measures around here. :-(

I looked around for a nice way to ban attackers who try to get into my machines and settled on DenyHosts as my favorite. One emerge later I was editing the configuration file, and after I got done with that the trouble started.

First sshd completely ignored the /etc/hosts.deny file that DenyHosts 2.6-r1 writes into. Maybe I forgot to install tcp-wrappers? Nope, those are there. Maybe I forgot to build sshd with the tcpd USE flag? No, that's there. It turns out that the default sshd configuration will bind to all interfaces on your machine, and for some reason that leads to entries in /etc/hosts.deny not being respected. The details are muddy, at least to me, but adding a ListenAddress your.ip.here.please solves the problem. And you gotta put your actual ip address!

So once that's working, I try the init script to (re)start DenyHosts. And it fails. At least that's what the init script says, in htop I can clearly see that I have a denyhosts process running now. What do you know, the init script that comes with Denyhosts 2.6-r1 on Gentoo is broken. You need to replace --name denyhosts with --name /path/to/python instead. Yes, you'll have to change it every time you update the Python interpreter to a new major version. What can I say? Someone needs to rewrite the init script from scratch I guess.

So now I have DenyHosts running, and script kiddies who try to get into my machine are banned. What else could I wish for? I don't know, a similar tool for Apache maybe? :-D

Sunday, September 6, 2009

The Domains of JHU

Don't ask me how I got into looking this stuff up, what matters is that I did look it up... :-D Apparently Johns Hopkins owns somewhere between 200 and 450 domain names. I am not sure how reliable the statistics are, but here are the links to what I saw:

low estimate
high estimate

Yes, I took the liberty of rounding the numbers, both up and down. I started wondering how many domain names other universities own. Here's my biased sample (data taken from the same site):

harvard.edu 242-391
yale.edu 186-405
princeton.edu 50-247
umd.edu 86-479
ucsd.edu 48
uci.edu 19-53
umbc.edu 4-8
ucr.edu 4-7

And just for reference, microsoft.com has 24,609-29,017 domains associated with it. So while we at JHU are "small fish" compared to M$, it's still somewhat surprising to me that universities, especially some who consider themselves "Ivy League," are domain hogs. :-)

Friday, April 17, 2009

Cooling Down Your Hot iMac G3 Server

I had a post here long ago about how the local ACM chapter handed me two old iMacs. About time I did something with them! :-)

Well, one of them, the faster one, got a CD stuck in its throat, so that's something for a later post. Slot-loading drives be damned! But the really old one, the original Series A iMac they gave me, is alive and kicking: Meet Zach!

As you can see, I am running Gentoo Linux on it instead of my usual choice for old machines, NetBSD. Turns out that NetBSD is a real bummer on these machines and that Gentoo just worked right out of the proverbial box. I even did the install remotely and it booted properly the first time, something that never worked out for me before. Excellent!

Well... Not quite. :-( At first I had the same problem I had when I ran NetBSD: the display wouldn't shut down. Now these old iMacs get really, really warm when the display is on. Not actually hot, but really, really warm. So running that thing as a 24/365 server wasn't really an option at first. But now it is! :-)

Thanks to my pal uber, I figured out how to make the monitor power down. Now I have a quiet and cool PowerPC server, just the thing I needed to be a little happier. Here's how you do it:
setterm -powersave powerdown
setterm -powerdown 1
setterm -blank 1
For some reason I had to do all three, not exactly sure why the last one is needed. But in any case, now the display shuts off after one minute. You have to run these from the actual console, but you can also add them to whatever local startup file your Linux distribution uses. On Gentoo, you can slap them into /etc/conf.d/local.start for example. Presumably your kernel has to support power management somehow (not really sure about that). Just in case I checked my kernel configuration, and the only thing related to power that I have set seems to be this option:
CONFIG_APM_POWER=y
As far as I can tell, one kernel option (which is a default on most Linux distributions I think) and three commands in a local startup file is all it takes: You can all turn your old iMacs into sexy servers now! So join the revolution! :-)

Zach has been running for about two weeks without any problems, heat or otherwise. The only painful thing with Gentoo is that everything gets compiled from source, which can take over a day on a slow box if you have to build gcc as well. Hint: USE="-fortran" is your friend. Eventually I'll look into distcc more seriously so modern boxes can do the grunt work instead of those tiny little PowerPC chips. Probably a blog post for next year...

Tuesday, February 3, 2009

Overdue Update

Well, it's been a while. :-) Since my last blogging craze I have been busy working mostly on stuff related to the Johns Hopkins Gaming Lab and the new course we're offering this semester.

In addition to the file server, I've built two gaming machines which are (or will be for the second one) over in the Mattin Center, ready for our students to crank. I have pictures of those two builds, but I am not sure I'll have the time to post them soon.

The course is going pretty well, teams are assembled and have mentors, and the first meetings and blog posts are starting to appear. Woohoo! :-) Might be a good time to thank everybody who is helping with our efforts: Thank you! (This thank you applies to all of you, you know who you are!)

I expect to be quite busy for the rest of the semester, but maybe I can make it on here every now and then to let you know what's up. In the meantime: Play more games! Hack more on your games! And enjoy your stay at JHU... :-)

Friday, November 7, 2008

Destructive String Operations Suck

Some of you may know that I started maintaining a 20+ year old assembler sometime in March this year. Sadly enough, most of my time so far has been spent on refactoring. The reason is simple: I often can't fix a bug or add a feature the users want because I run into some impenetrable wall of code that nobody in their right mind could possibly want to grok. :-(

So I bite the bullet for everybody else, try to understand the code without going nuts, and then rewrite it at least somewhat more cleanly. Drudgery for sure, but not without merit since I keep learning quite a few things in the process. Yes, I still learn new things about programming! Nobody is ever really done learning this stuff, even when you teach it year-in and year-out.

In my recent refactoring travels, I have finally recognized The One Big Truth about string operations: They should never be destructive. Not ever!

Case in point, I had a cute little function char *strlower(char*) that converted a string to lower case destructively, mostly because it's simpler to write the code that way. Of course, as I started putting more and more const into the code as part of my refactoring, I kept having to work around this function in various ways. Today it finally got too annoying, so the function lives no more. 8-)

The new function is size_t strlower(char *dst, const char *src, size_t size) instead, somewhat obviously inspired by strlcpy and strlcat of BSD fame. Granted, the rest of the code is now full of local buffers, but that's better than having to contort myself around a destructive string operation.

Of course, now that I've made the changes and written this blog entry, I have the weird feeling that this is going to bite my again later. Nothing like making a really embarrassing mistake to learn something about programming, eh? :-)

Update 2011/10/09: Sad but true: I've not been able to keep up my maintenance work as well as I would have liked. Also, I've learned something more important in the meantime: You better decide between maintaining messy code and rewriting messy code when you embark on a project like this. Today, if I were to go back to this project, I'd run two concurrent branches in a git repository: One with fixes to the old code, and one with conservative refactorings that don't change the deep structure of the product. Oh well, live and learn.