How to check the progress of dd
August 23, 2008
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
August 22, 2008
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.
(Jump to the fix if you want to skip the introduction.)
Google Sites is the evolution of JotSpot. It allows individuals, teams, or organizations to create simple, revision-tracked web sites. Probably its strongest points are ease of setup and ease of embedding other objects, including Google documents, videos, slideshows, calendars, and any of the “gadgets” available to iGoogle home pages. The most obvious downside is frustratingly limited customizability, as is to be expected from a free hosted solution.
Another problem is that saves can be less than perfect. Configuring and adding gadgets can be particularly frustrating, as you may find yourself starting over several times. Read the rest of this entry »
InfoQ: Intro to Google Charts and gchartrb
June 6, 2008
Matthew Bass has written a nice introduction to the [dead simple] Google Charts API and to gchatrb, a Ruby interface to the API developed by Deepak Jois. (The article links to an older Google code repository. The latest version is at the github link provided here.)
Constructing the URLs for Google Charts is pretty simple, and gchartrb and its Python counterpart are almost as verbose, but it’s obviously easier to integrate the wrappers into a program’s flow.
I like Bass’ idea of using a Capistrano task to update the image, rather than rendering it from Google every time. He is a little harsh, though, on “the medieval monster which is ImageMagick.” I like ImageMagick. I’m awful with anything related to design, images, and the visual arts; but I often find myself lost in the (wrongly placed) ImageMagick docs trying out all sorts of esoteric combinations to do some stupid trick or the other. It may be one of the worst tools to have to get work out of, but in the end it does a pretty nifty (and usually not-quite-what-was-expected) job. If ImageMagick is a medieval monster, it’s Herbert the Timid Dragon:
French annulment
June 5, 2008
There’s a story which seems to have hopped over from the French blogosphere now making the rounds. Read the rest of this entry »
Usability or lack thereof
June 3, 2008
A few ongoing issues are building up my frustration level today. Note that these are not all strictly about usability, but if I allowed myself to title all posts “Frustration,” this blog would be worse than K-Menu (see #4): Read the rest of this entry »
The Open Source swear jar
May 22, 2008
Jeff Atwood this week offered the world an article on the fact that “PHP sucks [but it doesn't matter.]” For a man who’s usually quite thoughtful, the critique presented in the article made it look like he’s been stuck on the LOST island with cached Slashdot discussions for a few years and he hit his head really hard and lost the ability to tell whether he’s actually saying anything of value or not. The substance of the apologia on the other hand - that in spite of sucking, PHP powers the web’s biggest and busiest - was put forth much more ably by Terry Chay in his thesis on the science fiction mythology behind the enterprise of the Enterprise.
However, I think Atwood has been redeemed by the fact that his piece provoked the following gem from Stanislav Malyshev: “I wish for every 50 ‘PHP sucks’ blogs people would write one good RFC.”
Read the rest of this entry »
Letting go of normalization - an introduction
May 21, 2008
The Google App Engine discussion list has been fairly active with people trying to rework/rehabilitate their relational database habits and knowledge to the strengths and shortcomings of App Engine’s Bigtable-based Datastore. For many, the pondering starts with “um, OK, how about JOINS?” That question keeps coming up, and there have been a few proposed substitutes.
If one even slightly “gets it” though, the next step is to try to figure out the new paradigm at work here. How do we need to be thinking about the design of our queries, our models, and our applications as a whole? There’s a dearth of documentation, successful code examples, and explicated best practices. The discussion list has been slowly filling up that hole. At the heart of much of the advice being gathered there is the need to denormalize data. All data should be accessed via models designed with a view towards the ways in which the data will actually be used. A little extra effort should be applied while storing data to optimize it to be ready for use on read, so as to avoid complicated joins and unnecessary hits to the datastore. And other such points counterintuitive to the relationally-trained mind.
Now Todd Hoff has written the best overview of the issues I’ve seen to date, titled “How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale.” This is definitely recommended reading for anyone starting out with App Engine, required reading if you’re thinking of porting an app (say one based on Django with a MySQL back-end), and remedial reading if you built (or started to build) an app where you tried to emulate what works in relational databases, and found something off.
With the good comes the bad
May 13, 2008
Adding temporary space to /var for apt
May 11, 2008
Say you have /var on a separate partition for whatever reason, and the space is enough for your usual needs, but you all of a sudden have to install a massive set of new packages all at once, most likely for a version upgrade. If you’re in an apt-based system (Debian, Ubuntu, and friends) you’ll likely see a message like this:
E: You don't have enough free space in /var/cache/apt/archives/.
Fortunately it’s fairly easy to fix this temporarily without worrying about resizing the partition. You’ll need a partition or external storage at least as large as the amount of archives it says it needs to get. We’ll assume you mounted this at /media/bighonkindrive. Now all you have to do is:
$ sudo mv -i /var/cache/apt /media/bighonkindrive
$ sudo ln -s /media/bighonkindrive/apt /var/cache/apt
(Or switch to a root shell and drop the sudo. And the -i just makes sure anyone reading this who happens to have an “apt” file or directory in their bighonkindrive doesn’t curse my name. And you could presumably do the same for just the /archive directory, but why not keep it all together? ) Then run your upgrade. When it’s done you can do:
$ sudo apt-get clean
$ sudo unlink /var/cache/apt
$ sudo mv /media/bighonkindrive/apt /var/cache
And we’re done. Yes, this should be obvious, but sometimes the brain sticks. If this is really stupid, or there’s a better way, or whatever, please let me know.
