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

eBay Scam with Bidpay

For future reference, I don’t think I’ll ever purchase something through eBay again without using Paypal — at least with Paypal, if something goes wrong, you can generally get your money back. In this case, I used a legitimate-looking service called “Bidpay.”

The next day, I got a note from eBay’s Loss Prevention Department:

Our records show that you were a bidder or buyer of one or more of this seller’s items. We recently removed this seller’s active listings and suspended the seller’s trading privileges. Due to privacy concerns we cannot share further details about this seller.

Checking eBay, the auctions have been unceremoniously removed. It doesn’t appear that Bidpay has charged my card, perhaps they caught on to the scam, but their policies in this regard are somewhat obnoxious.

Also somewhat obnoxious — the auctions disappear from eBay, including MyeBay and history, as if they never existed. This makes these sorts of things difficult to keep track of.

At any rate, although I’ll have to monitor this credit card usage for a while, just in case, at least I’m not retarded enough to use a debit card or a direct draw from a bank account.

So, a big, hearty “Good Job Sucking” goes out to Bidpay, for this exchange:

Question
This and order number 29965909 were apparently posted on eBay by a fraudulent seller. I received this from eBay:
(see quote above)

Discussion Thread

1/22/2007 1:39:00 PM — Your question was submitted to BidPay Technical Support

1/22/2007 1:58:10 PM — BidPay wrote:

Order 29965906, 29965909- Item Not Received

Dear xxxxx,

This is in response to your report that your auction item has not been received, or is not as described. BidPay will initiate a dispute and will act as an advocate on your behalf to first resolve the issue with the seller. If we are unsuccessful at the end of the dispute process, we can attempt to recover your money from the seller’s bank account. The process typically takes 3-4 weeks.

The dispute process includes attempting to contact the seller. Bidpay will attempt to contact the seller twice within 2 weeks. If the seller does not respond, BidPay will then attempt to debit the sellers bank account. If the first attempt to debit the seller’s account is unsuccessful, BidPay will attempt a second time. The debiting process can take up to two weeks.

So, here’s to you, Bidpay.  Good Job Sucking.

Share

So it begins

I’m not a big fan of blogs, since my experience with many has been similar to reading fanfic, somebody’s personal diaries, or the text surrounding second-rate pornography.

With that in mind, my goal here is not to create any of those things, but instead to have a repository of things that are useful:  for example, technical information that I’ve had difficulty locating, sources of parts and the other sorts of things that I would actually find useful.

Share