Thursday, May 29, 2008

EPrints, SPAM & deleting users

We run an instance of EPrints 2.3 and noticed recently that it was getting lots of SPAM. Well, more specifically, that a lot of spammers had registered accounts on the system with meaningful usernames like "cunnilingus". Fortunately our self-archiving policy requires that user submissions are approved, but nevertheless the multitude of irrelevent accounts was irritating.

It was then that I discovered that EPrints doesn't have a command-line way to delete users. There's a create_user, but no remove_user. Not being one who is daunted by such problems, I set about writing one. It turned out to be quite simple.

Since I'm a firm believer of making the wheel available, here's what I came up with. YMMV and all that.

posted by guy at: 09:04 SAST | path: /systems | permanent link

Sunday, May 25, 2008

Ubuntu 6.06 LTS to 8.04 LTS on a Xen VPS

I've just upgraded the server hosting this blog from Dapper (6.06 LTS) to Hardy (8.04 LTS). I started by following the instructions, which seemed simple enough.

Unfortunately, as apt started processing the post-install configurations I started seeing a lot of errors Lots of packages (apache, mysql, amavis, etc) had --configure fail with errors like:

Segmentation fault
dpkg: error processing w3m (--configure):
 subprocess post-install script returned error exit status 139

Googling the problem produced this, which suggested the problem was related to the fact that the machine in question was a VPS running under Xen. The suggested solution was to uninstall libc6-i686 and replace it with libc6-xen. Unfortunately I didn't have libc6-i686 installed, and installing libc6-xen didn't help ...

After much head scratching and experimentation, I stumbled across the answer. Or more realistically, I figured out what the failing packages had in common and it triggered a distant memory. All the packages use crypto of some form. SSl or TLS. And I vaugely remember that Xen has a problem with TLS that I had to fix in 6.06.

The suggested solution is to rename /lib/tls to /lib/tls.disabled. I'd already done this in the past (the directory was there as evidence), but the 8.04 upgrade had replaced /lib/tls. Sure enough, removing the directory fixed the problems :-) I then installed libc6-xen, which put in a Xen-friendly /lib/tls.

posted by guy at: 23:58 SAST | path: /systems | permanent link

Saturday, October 27, 2007

IPv6 for Raccoon

We've recently set up an external server at LayeredTech to provide us with a remote DNS server, secondary MX, etc. I've got no complaints about LayeredTech — thus far they've been great. But earlier this week I decided I wanted something they couldn't provide.

All our core services on campus are IPv6-enabled, including hippo.ru.ac.za which provides an IPv6 CCTLD for about seven countries. So naturally we wanted to IPv6-enable the machine at LayeredTech. For one thing it'd help us with testing. More importantly, however, we believe it is the right thing to be doing on the current Internet.

Despite reading on their support forums that LayeredTech had no immediate plans for supporting IPv6, I noticed that they'd got a LIR allocation from ARIN. A little hopeful, I e-mailed LayeredTech's help-desk. They confirmed that IPv6 is work-in-progress, but isn't yet available to their customers.

All isn't lost though. The good folks at SixXS provide free IPv6 tunnels for people in our sort of situation. So I went through their (reasonably painless) registration process and now have a tunnel ending at OCCAID. It's not exactly what I wanted (i.e. native IPv6), but it's perfectly adequate for the sort of testing I want to do.

If anyone's in the same boat as us, I recommend SixXS.

posted by guy at: 16:58 SAST | path: /systems | permanent link