Use ImageMagick to make a pdf from a set of images

$ convert *.gif mydoc.pdf

Thanks again, ImageMagick.

Debian – choose your Java

Say you were using purely gcj from forever but you run across an application which discriminates against it. If you install Sun’s java (jdk/jre/jwhatever) and out of caution or nostalgia don’t uninstall gcj, how do you make sun-java the new system default?

#update-alternatives --config java

WRT-54GL at decent prices.

While we’re on an OpenWRT kick, let me mention that Amazon has the guaranteed flashable WRT-54GL for less than $50 again. I won’t even provide a non-referral link, so as not to raise eyebrows at wordpress.[non-]com[mercial]. I’m sure you could find it.

Possibly the best reason someone who’s not interested in getting to know their network or doing fun things with it is the possibility to use just one OpenWRT/DD-WRT/Tomato device (along with any standard wireless router) to extend internet connectivity to another part of the house without running wires or using shaky (and unencrypted) Power-Over-Ethernet.

On my list of future projects to waste my money on, though, is a set of cheap 802.11n devices, replacing the “G” bridges I’ve had for the last few years. Apparently, that day is near or already here. Of course “N” speeds only matter if you’re concerned with moving data between machines in the home. For a normal residence, any available residential networking technology is faster (in most cases orders of magnitude faster) than even the best of the universally crappy available residential internet connections, and so the bottleneck will always be at the WAN side (especially for upload.) Of course these days, most small businesses are actually paying more for even crappier Internet service. But I digress…

On a last OpenWRT note, if I had known about this contest in time, I definitely would have put together a team and devoted a few months. Maybe it really does pay to read Slashdot.

LTSP 5 with OpenWRT Kamikaze 8.09 DHCP

OpenWRT Kamikaze 8.09 processes /etc/config/dhcp and appends the settings specified there as command line options when running dnsmasq. To properly configure dnsmasq to point to your LTSP server you will both need to specify options in this file, and modify the dnsmasq init script for these new settings. (Note that you can also—right now—add an /etc/dnsmasq.conf with these options in standard syntax. But that’s not the way OpenWRT is heading, and there’s inconsistency across the various packages as to the use and naming of non-uci config files.)

The following worked for me with Debian Lenny running LTSP 5.1.10 installed fromt the repositories, other distros may require different paths:

In /etc/config/dhcp, add in the “config dnsmasq” section:

option dhcp_boot ltsp/i386/pxelinux.0,$LTSP_SERVER_HOSTNAME,$LTSP_SERVER_IP
option dhcp_option 17,'$LTSP_SERVER_IP:/opt/ltsp/i386/'

The first path is relative to /var/lib/tftpboot, the second is the ltsp chroot directory which should be in /etc/exports. The second option is equivalent to the root-path option offered by dhcpd (AFAIU) and solves the “need path” error. Apparently this is not necessary when the DHCP and LTSP servers are the same.

Etherboot clients may require different path information. And if you have a mixed set of clients, you can use the dhcp-vendorclass syntax demonstrated here (the paths in the dnsmasq section of this document are out of date, though they have been fixed in the rest of the page.)

In /etc/init.d/dnsmasq add in the “dnsmasq()” function:

append_parm "$cfg" "dhcp_boot" "--dhcp-boot"
append_parm "$cfg" "dhcp_option" "--dhcp-option"


Run:
# /etc/init.d/dnsmasq restart

Then boot one of your thin clients, hopefully to an LDM login screen.

(Credit where credit is due: This post on general PXE booting with Kamikaze got me halfway to getting this to work.)

Which version of OpenWRT is this for?

OpenWRT is one of those great projects which suffers for lack of documentation. Even worse, there have been three generations of configuration methods, and the existing documentation and user-written howtos can often be vague about which version they refer to. Some commands are future compatible (meaning they will work on later versions of the firmware) and some are not. Some may work, but in less than optimal ways and leave you with a mess to maintain in the long run.

(A similar problem exists with Xorg where many, many users who aren’t and don’t want to be X gurus but who know a few tried and true xorg.conf hacks have gone into their systems over the last year only to discover they no longer have an xorg.conf. Now, maybe you can just add a file to replace the non-functioning background magic, but you’ll be left wondering what you’re giving up, what might break down the line, and so on. And you probably wont find a simple answer for a modern system yet. You’ll have to wade through mountains of mailing list and forum postings, and reconstruct the workings of the new style X server in your own mind, which is exactly what you wanted to avoid.)

So, for those who don’t pay much attention to these sorts of goings on in OpenWRT land (how often do most of us reconfigure our networks?), here’s a set of rules of thumb for recognizing the version of OpenWRT any given online tutorial applies to:

• If you will be changing NVRAM settings, it’s for the old WhiteRussian release. (You should probably upgrade if you’re still using this.)
• If you are editing config files which resemble those of a normal Linux system in /etc, it’s for Kamikaze 7.x series. Many of these config files will still be read in the current 8.09.x series if present, but don’t necessarily count on it. You should be able to figure out the launch process for each package by reading the init scripts.
• If you are editing files in /etc/config or using uci, this is for Kamikaze 8.09 or later. In this series the LuCi web interface is also on by default, if that’s your thing.* Occasionally something shows up in the forums which uses uci directives which don’t seem to exist in stable. Also, you may find yourself adding options which the init scripts do not yet process, so you will have to edit them in.

OpenWRT is indispensable, and like much great software, those using it would rather keep using and improving it than document it and clean up the existing mess of documentation. Hopefully this helps with a little of that weeding for the new user.

* You can remove the LuCi web interface from OpenWRT Kamikaze by killing the process and running:
opkg remove -recursive luci-*

Epoch Fail Screen Cap

48 seconds...

Making ksh history persistent in OpenBSD

There’s an environment variable HISTFILE which determines where ksh saves your command history. By default, if HISTFILE is not set, ksh will save to ~/.sh_history. OpenBSD does not, however, include this default – so your command history is lost at the end of each session. That may be what you want, but if not, you can just add a line like this to ~/.profile:
export HISTFILE=~/.sh_history
Since ksh doesn’t include source you can use . ~/.profile to load your changes.

Adding Eterm backgrounds

This is one of those “I know I’ve bashed my head over this before and Googling doesn’t necessarily get you to the right place but reading the docs or running the right command with –help would fix the problem right away” type posts.

Assuming you want new backgrounds available to all of a systems users, put the images in tile/ and scale/ respectively under /usr/share/Eterm/pix (on Debian and probably most systems). Then run (as root or with sudo) “Etbg_update_list” – and here’s the “i’m such an idiot that I couldn’t figure this out part” – with the full path to pix/ (or run it from within pix/ since it defaults to the current working directory.) Then you can partake of the full hideous beauty which is random Eterm backgrounds.

How to check the progress of dd

You probably know this, and if you didn’t you should have read the man page before coming here, but:
kill -USR1 $pid
(with $pid being the pid of a running dd process – which you can get from ps) will cause dd to pause, print out progress statistics, and resume copying. Awesome.
(It outputs in the terminal where dd is running, not where you enter the kill. Just in case you’re looking.)

Automating VoIP device configuration with wget

Over the last month or so, I’ve been doing assorted tasks for the Lehigh Valley’s premier business VoIP provider. One of the more tedious VoIP related tasks is getting out-of-the-box VoIP hardware from its factory default state to fully configured. Nearly all hardware accepts some sort of remote provisioning, but you have to somehow let the phone know the path to the provisioning server (as well as related settings.)

In some cases, you can use DHCP option 66 and specify a TFTP server as you might for other netbooting devices. But in a situation where your providing phones to clients for a Hosted PBX (and in most other situations) TFTP is less than ideal, and relying on control of the DHCP server is unrealistic.

There are (usually) two more ways of providing the configuration information: through the phone’s user interface, and through the web control panel. Just grab your (non-fully-keypadded) mobile and dash off a text message with a link to a Google Maps URI and you’ll get a sense of what the first option is like. The second is only slightly less tedious.

Fortunately it’s not so difficult to tease out the http requests the web interfaces for the various phones need. (Firebug, or at least “View Source,” is a tremendous help in this. Tamper Data, or similar tools, can help in making sure things really work the way you think they do.)

With this information we can build up command line scripts with which we can automate the process of giving phones their initial configuration. prov.rb is a Ruby-based application I’ve been working on which configures phones one phone, IP range, or subnet at a time, logs MAC addresses, and more. (I’ll be committing to GitHub as I get time over the next week. I’d love help working out the kinks, and especially for adding more hardware varieties.

In the course of working on prov.rb, I teased out the POST requests for configuring all of these basic settings on both Aastra and Grandstream phones. In addition to writing a client in Ruby, Python, Perl, or whatever, one can also make these requests quite well with cURL or, my preference, wget. So, in the next two posts I’ll provide sample commands for these two brands of phones:
(I’ll add the links once I write the posts.)

Of general interest is that each company (similar to nearly every other maker of VoIP and networking hardware) use largely identical web panels across their product range. This means the same script will work with basic ATAs as with high end phones and gateways. This is especially true if you are just setting a provisioning path for the phones to get their specific configuration.

The main difference between the Aastra and Grandstream panels is that Grandstream uses cookie based authentication, while Aastra uses basic http authentication. Neither of these would do anything to secure the phones in a hostile network environment, so I won’t even speculate on the reasons for the choice of one over another. The basic authentication is a little simpler to manage than cookies with wget, and you’re not stuck with an extra file to clean up.

If your provisioning lab/supply closet/garage is anything like ours, you probably have quite a few OpenWRT boxes laying around. OpenWRT does include wget as part of Busybox, but this is a crippled minimal version of wget, which is missing options for cookies, authentication, and even manual setting of headers. I believe there is an ipkg available for a full version of wget, which could be useful. I’m still looking forward to installing the Ruby ipkg for use with prov.rb.