Mail, DNS entries, and domains

I recently overhauled bits of the mail system here to take care of a few lingering quirks that I’d never had the time nor inclination to track down. All of my various email addresses and aliases go to the exact same mailbox, through the multiple expedients of fetchmail, which picks up my mail from gmail and AOL, and DNS MX records that point everything to the same place.

Until recently, if you sent mail to “user@goodjobsucking.com” it would be transformed by the server into “user@baddomain.com” unceremoniously. It would show up that way in the mailbox, and only by delving into the mail headers was it obvious that the mail was originally destined for a different domain. For addresses I didn’t make use of much, this was fine, though it leads to the curious circumstance where somebody sending mail to goodjobsucking.com would get replies from baddomain.com, which deviates from the principles of separating domains in the first place.

It turns out the root cause was that goodjobsucking.com, rather than having its own A record in the DNS tables, used a CNAME to baddomain.com. Apparently this implies that mail sent to goodjobsucking.com is actually for baddomain.com. I imagine this would be particularly useful for adjunct or typo domains, where you want to correct the original destination or transition from one domain to another. It’s also useful in that the mailer only needs to internally relay for, and listen to, mail destined for baddomain.com; any mail sent to a CNAME from another domain pointing to it works perfectly well.

Moving the domain from a CNAME to an A record effectively separates things out again, though now the mailer must also be aware that it’s listening for mail for yet another domain.

Share

LaCie 1TB NAS

LaCie has a wonderful little NAS box called the “Ethernet Big Disk” that comes in a 1TB size, supports USB and gigabyte ethernet, and is reasonably priced. The NAS part supports smb, afs, ftp, and http, which makes it pretty darned useful out of the box.

Even better, it sports a version of embedded Linux on an ARM CPU:

Linux version 2.6.12.6-arm1-lacie5a (root@lacie) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #1 Tue Oct 31 11:26:21 CET 2006CPU: ARM926EJ-Sid(wb) [41069260] revision 0 (ARMv5TEJ)

Naturally, it’s a prime target for hacking in some useful things. This can be accomplished in several easy steps:

  1. Open it up and pull out the drives
  2. Mount the SATA drives on another Linux box
  3. Add an exploit to the web server (which runs as root, making the rest easy)
  4. Put it back together
  5. Make yourself a root account
  6. Cross compile some binaries and copy them useful places
  7. Give yourself a command line

Okay, so up until step 5, it’s pretty straightforward, and documented here and here. Actually, even making a root account is pretty straightforward; using the web exploit, you can copy passwd and shadow to the NAS share, edit them, and copy them back. I chose to add an account called “myroot” and leave the default root account’s password alone, just in case it’s needed for … something.

Building a cross-compiler is, frankly, a major pain. However, once I got it built properly (in my case, using a handy port for the MacIntosh) it was fairly straightforward to cross-compile utelnetd and rsync. utelnetd can actually be launched from the web exploit, and it’s possible then to log in directly as root.

For those who appreciate a kick start, here are the compiled binaries that run on the LaCie. (Naturally, these are without any warranty of any kind, and whatever happens to your NAS is your own fault, etc.)

lacie.tar.gz

I can’t think of much more one could want than telnet, rsync, and nfs. Well, maybe ssh, but it’s been done, and I don’t really need it.

Share

Rsync over SMB

This is a short one — I was using rsync to back up about a terabyte of data, which suffered a number of interruptions. Each time it restarted, I noticed it was copying over the same files over and over again. As it turns out, SMB rounds off the time stamps to the nearest two-second interval, so when rsync compares timestamps, it believes the file is different.

There’s a simple solution:

rsync -rlptDv –modify-window=1 [source] [destination]

The “–modify-window” switch tells rsync to relax its timestamp comparison just enough for it to behave.

The remaining switches are useful for backing up to a NAS box, it’s essentially -a (archive mode) expanded, but without preserving ownership or groups (which doesn’t work well on the NAS.)

Share

HDD LED for add-on cards

Among the many little things that irritate me, it’s when you have a computer case with multiple drives in it, attached to multiple add-on cards as well as the motherboard, but (of course) there’s only one hard drive LED on the case — so you get to pick a controller card to drive the lights on the case, and … well, I suppose you can be happy with that, especially if you don’t pay it much attention.

When looking for a simple cable to combine the inputs, I realized that I may be part of a subset of the larger population, the subset who wants their leds to behave themselves whether it really matters or not. Either my skills with Google are not up to snuff, or there is no such animal commercially available.

Partly it’s because if you’re hapless enough to simply connect them all in parallel, you’re likely to burn out your case led the moment there’s activity on more than one controller card. So slightly more complex circuitry is necessary to make the lights work.

Lying around, I had a tiny case, optocouplers, and resistors, so I had to get power connectors, header connectors, and a breadboard — but there’s really not much more to it than that.

Case open

To the left, the circuit assembled on a breadboard in a little case — to the right, is a sketch of one of the optocoupler circuits. And here’s what it looks like with the case closed:

Outside

Share

Skipping the FreeBSD vulnerability check during portupgrade

FreeBSD has an excellent facility for checking its ports for vulnerabilities provided by security/portaudit. This is very handy when installing an unknown package. However, it can be quite a hindrance when upgrading from one very vulnerable version of a port to one with fewer vulnerabilities, since portupgrade will flatly refuse to upgrade the port, with this kind of error:

===> wordpress-2.2.1,1 has known vulnerabilities:
=> wordpress — unmoderated comments disclosure.
Reference: <http://www.FreeBSD.org/ports/portaudit/6a31cbe3-1695-11dc-a197-0011098b2f36.html>
=> Please update your ports tree and try again.

It’s best, of course, to confirm that the vulnerability is something you can live with. If so, you can pass a flag to “make” to have it skip the vulnerability check:

portupgrade -m -DDISABLE_VULNERABILITIES wordpress

Naturally, I wouldn’t recommend doing this in conjunction with “portupgrade -all” since it would defeat the purpose of having the vulnerability check at all.

Share

A Tale of Audio, Firefox, and X-Windows

The venerable X-Windows has network support with grace and elegance that other window systems (I’m looking at you, Windows) have yet to come anywhere near. Point your applications at any xserver on the network, and there they run — what could be easier? On the down side, this seems to have been developed before sound was particularly important, so without doing anything fancy, your application runs anywhere but (if you’re lucky) any sound it produces emanates from the machine running the actual application. This can be somewhat disorienting, at best.

The dubious goal: to get a flash game working on an x-server — one that doesn’t even have a browser installed.

The first step was to get Firefox/Flash sound working on the gentoo x-client. (It’s been gone over many times, but X appears to use these terms backwards, a tradition which I will continue.) Simple enough:

export DISPLAY=xserver:0.0
firefox

There’s firefox, but, no sound on either the client or the server. A review of what the terminal is spewing out shows:

ALSA lib confmisc.c:848:(snd_func_card_driver) cannot find card '0'
ALSA lib conf.c:3500:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device
ALSA lib confmisc.c:397:(snd_func_concat) error evaluating strings
ALSA lib conf.c:3500:(_snd_config_evaluate) function snd_func_concat returned error: No such device
ALSA lib confmisc.c:1248:(snd_func_refer) error evaluating name
ALSA lib conf.c:3500:(_snd_config_evaluate) function snd_func_refer returned error: No such device

Weirdly, other sound applications appeared to work perfectly well, albeit from the wrong box. Also weirdly, the card is clearly there and enabled, and ALSA is configured in the kernel (not as a module) with the correct sound card.

After a couple of useless dead ends, running Firefox as root revealed that it’s a permission problem. I can think of more useful ways in conveying this, but placing the user into the audio group takes care of that problem. Now I’ve got local audio, at least.

The next trick is to get the client (Gentoo) to send its audio to the server (FreeBSD) .

Share

EVMS and degraded RAID

I’ve been very happy with EVMS under Linux; it’s an excellent way to coherently tie together lvm and md and other mirroring, striping, and logical volume technologies, and has a nifty GUI for managing drive resources. I move drives around much more than I like, often due to the grim reality of bad sectors or filesystem crashes.

After building a RAID volume, a loose power cable on one of the drives caused it to immediate degrade. This shouldn’t be a big deal, since EVMS has a “remfaulty” function for its RAID-5 plug-in. Except that it doesn’t work. I’m not sure whether it’s missing or broken in my version 2.5.5, but it doesn’t work as documented.

Looks like the way to fix this is through md directly, using mdadm. The tricky part about this is that one needs to refer to the EVMS controlled devices, or it doesn’t work. So, to re-add the drive and invoke the synchronization process, one needs to run:

mdadm --add /dev/md0 /dev/evms/.nodes/sda5

Note the “.nodes” part of the command

Share

HP Image Zone and PVM files

HP Image Zone comes with HP cameras and printers, and is, in general, perfectly adequate for routine image printing and minor manipulation such as cropping, resizing, etc.

On the other hand, it’s remarkably opaque, having the concept of an “Album Shelf” onto which albums can be placed. Albums are collections of image files stored in XML, but with a PVM extension. However, there’s no apparent way to actually get PVM files onto an image shelf, so in the event of, say, a hard drive crash, you’ll apparently need to completely recreate any albums you might have had.

This is utterly obnoxious (not to mention unacceptable) so I actually contacted HP support, who told me that there was simply no way to import albums. One can create albums, I reasoned, and list of albums on the album shelf must be stored somewhere, after all.

After much screwing around, while tech support insisted that what I was attempting was impossible, I determined that this was all stored in

C:\Documents and Settings\[windows login]\Local Settings\Application Data\HP\Digital Imaging\db

The file format appears to be Foxpro, and there are a bunch of files in there.  Foxpro can open them, but what’s shoved into the text columns appears to be UCS-16.  The short version is that copying the database files from one installation to another copies the Album Shelf.

Share

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