Second-Hand

Edit: I’ve now backported the neccesary changes to v4l-dvb-makomk in order to make it compile on 2.6.24 (it was actually easier than I expected).

In case you haven’t noticed, both Markus’ v4l-dvb-experimental and my v4l-dvb-makomk are slowly dying. (v4l-dvb-experimental can be coerced to compile on modern kernels, but is old and unsupported; v4l-dvb-makomk is worse, since it doesn’t even compile on 2.6.24). So what should you use?

• For non-em28xx based devices that use the xc3028 tuner, try http://linuxtv.org/hg/v4l-dvb/ - support for that tuner and probably most of these devices has been added to here. If there’s anything of this sort that v4l-dvb-experimental supports and v4l-dvb doesn’t, it should be easy to add, and there may even be another tree at http://linuxtv.org/ that does support it (e.g. http://linuxtv.org/hg/~mkrufky/cx88-xc2028/). Try asking on the appropriate mailing list. (v4l-dvb-makomk never supported any of these devices, so if you’re reading this you probably don’t have one.)
• For em28xx-based devices (what v4l-dvb-makomk supported), you have a choice:
  • If you only want analog, your device may be supported by http://linuxtv.org/hg/v4l-dvb/. You can find a list of supported devices here, though other hardware may work with some small changes.
  • You can carry on using v4l-dvb-makomk, though I can’t make any guarantees about what’ll happen when 2.6.25 is released. It should now work on 2.6.24 if it did on earlier versions, which for most hardware was the case.
  • If you want digital, Markus’ userspace code may be your best or even only option. You should be able to find installation instructions somewhere, though I’m not sure there’s anything official
  • Finally, some hardware may require you resorting to v4l-dvb-experimental, though this is in a pretty bad state and getting worse.

Scientology scares me. Then again, even the IRS seems to be afraid of them.

Well, that’s the Mercurial repositories back up. I think that should be the last of the public-facing stuff; the rest can wait.

Well, I managed to get my new VPS set up and working. Then random programs started segfaulting, to the point where it wouldn’t boot up. I pulled the affected programs off and ran clanscan over them - they were infected by the Linux.RST.B-1 virus. Shut the VPS down, started pulling the important data off via the web-based admin console, and went to check my e-mail. Hey presto - an e-mail saying that the provider had been getting reports of SSH brute force attempts from my box, sent at about the same time I’d started seeing issues.

Took a look at the logs, and there was a ssh brute force attempt followed by a successful login as root from a strange IP yesterday evening. I don’t login as root to ssh ever - in fact, I wasn’t even sure if it was enabled. Of course, this left the question of why the attack succeeded - sure, the VPS came with a horribly insecure root password, but I’d reimaged it and changed the password before ssh had even had a chance to start. Turns out the management software (HyperVM) had its own idea of what the root password should be, and automatically reset it to that on every boot. Since I don’t use the root password, I didn’t notice.

(The management software is interesting in itself. For example, it stores the root password in plaintext, and it inserts it into /etc/shadow using the ancient and not particularly secure DES-based hashing algorithm. I also wouldn’t like to make any bets on the security of the web administration interface in general.)

Finally got round to reinstalling WordPress after the bout of massive filesystem corruption that took out the last installation (along with the rest of the virtual server it was installed on). It’s only two or three months since then…

This time round, I used Debian’s package. I can’t be bothered to keep up with security fixes myself, so I’ll leave it for them to keep track of. After all, now that I’ve found that nice script for e-mailing me about pending updates to packages, I may as well make good use of it…