Web Remote Control

The words “web” and “remote control” are used together to describe all manner of things, but here I’m talking about a remote control of a PVR, using a web page. In these days of wireless connectivity, and distributed video, it’s almost a natural thing to want to be able to control stationary equipment from a roaming laptop or tablet computer. It seems that this is the sort of thing that many people would have done before, but my searches were fruitless.

It turns out this sort of thing isn’t all that difficult to brew from scratch, although there are a lot of little pieces that need to be properly strung together. Starting from the PVR itself, an infrared emitter is necessary that’s compatible with lirc. (Consult the lirc documentation for a list of compatible emitters, and instructions for rolling your own.)

Lirc itself needs to be installed and working properly; I won’t attempt to duplicate the documentation, which is fairly straightforward, but I ran into two snags. First, lirc on gentoo requires a USE flag to be set in order to transmit at all — Gentoo has some excellent supplemental documentation here. Second, not all the buttons were represented on my remote. This was easy enough to rectify starting with the lircd.conf closest to my equipment using the irrecord tool and some hexidecimal math. (Obviously, this required that I also get lirc working as a receiver, but all I really used it for was adding additional codes.)

My Remote Next, I located a picture of my remote. The basic interface idea is to have a web page where the user can simply poke each button. They’re a little hard to read in this image, so this could be considerably improved, but realistically, after using the physical remote for a while, the positions and functions of the buttons become second nature.  In addition, rolling over each button gives its function (albeit in an ugly way; this can be improved, too, of course.)

A standard image map is used to make each button clickable. To prevent annoying refresh and latency issues, simple AJAX techniques are employed to send each button press to the web server behind the scenes.

Here’s the actual code of the pages:

pushbutton.php —
<?php
echo ‘irsend SEND_ONCE dish2 ‘ . $_GET[‘button’];
system(‘/usr/bin/irsend SEND_ONCE dish2 ‘ . $_GET[‘button’]);
?>

Continue reading

Share

FreeBSD upgrade from 5.5 to 6.2

It’s finally time to upgrade FreeBSD on my main server, and there doesn’t appear to be a ton of information on how to do so using sources. Although I successfully upgraded a FreeBSD workstation using binary methods, I have a mildly customized kernel on the main box, and I generally just prefer to use source/CVS based updates, because that’s how I keep it up to date, anyway.

Step 1: Synchronize the source using a 6.2 cvsup file.

This file resides in /usr/share/examples/cvsup/stable-supfile; the only thing one really needs to do is replace “RELENG_5” with “RELENG_6”, and then run
cvsup -g -h cvsup.freebsd.org /usr/share/examples/cvsup/stable-supfile

Step 2: Make buildworld

Go to /usr/src and type “make -j4 buildworld”. In my case, it died because a file it was trying to build (“lsof”) already existed. I’m not sure why this would be so — perhaps I should have started with “make clean” — but simply deleting the file allowed it to move on and build everything.

The “-j4” part is optional, but it speeds things up by using parallel builds, so I can’t think of a good reason why not to include it.

Step 3: Build the kernel

There are a number of ways to do it, but this works:

make buildkernel KERNCONF=MYKERNEL

It doesn’t look like kernel options have changed all that much, so I’m leaving my 5.5 kernel configuration intact. It appears to build without a hitch.

Step 4: Install the kernel

This part’s easy. “make installkernel KERNCONF=MYKERNEL”

Step 5: Merge configuration files

This doesn’t appear to need to be done in single-user mode, and mostly includes adding the _dhcp user and group, and the audit user. Start by running “mergemaster -p”

Step 6: Reboot into single user mode

Ideally, everything works at this point. If not, you should still have your old kernel to fall back on. You’ll need to mount all your mountpoints in order to take care of the next step.

Step 7: Install files

Also straightforward — “make installworld” from the /usr/src directory. The most likely trouble you’ll run into is having failed to install a required user or group. After this step, reboot.

Step 8: Merge configurations

This is probably the most tedious part of the upgrade, and pretty easy to screw up badly. To start, su – and run “mergemaster”. This will attempt to merge the plethora of config files from your instance and from the new distribution. As a general rule, you’ll want to go ahead and merge anything you haven’t touched, and pay careful attention to anything you have. It’s easy to get on a roll and let it (for example) replace your mail “aliases” file, which, if you’ve neglected to back up, can be a complete mess.

This is made somewhat more tedious by the fact that you have to approve every change, no matter how trivial. I don’t think there’s an easy way around this.The kernel config will have told you where the kernel build directory is, as well as reminded you to do a make cleandepend; make depend. After that, make and make install will get the kernel installed in the proper location.

Step 9: Reboot (again)

That should do it — it worked for me.

Share

fetchmail (and AOL)

For a number of reasons, I’ve kept my AOL email account, but have naturally incorporated it into a single mailbox using fetchmail and AOL’s imap interface. I noticed that fetchmail started doing this all of a sudden:

fetchmail[90687]: Server certificate verification error: unable to get local issuer certificate
fetchmail[90687]: Server certificate verification error: certificate not trusted

After some investigation, it appears that fetchmail is suddenly having trouble negotiating a TLS connection via IMAP. Beats me why — it either didn’t make the attempt before or something has gone funny on the AOL side — but aside from being vaguely annoying, it turns out that the mail still gets through, and these errors effectively mean nothing whatsoever.

Share