Posted by Tom Moertel Mon, 19 Nov 2007 18:07:00 GMT
Issue 9 of The Monad.Reader is hot off the presses! The issue focuses on three Google-Summer-of-Code projects for Haskell: Cabal configurations, Darcs’s Patch Theory, and the typechecker-framework TaiChi. Good stuff.
I know what I’ll be reading for lunch today.
Posted in haskell
Tags haskell, tmr
no comments
no trackbacks
Posted by Tom Moertel Thu, 15 Nov 2007 07:30:00 GMT
I recently started using Puppet to automate my server-build processes. The basic idea behind Puppet is that you create “manifests” that declare a directed graph of “resources” that represents the desired state of your machines. Puppet-managed machines on your network then query a master server to obtain the latest copy of the graph, which they then reconcile with their current states to make whatever changes are necessary to bring themselves up to date.
For the most part, everything works well. I have encountered a couple of snags when writing manifests, however, so I’m going to explain them here as reminder until I get the time to fix them in the Puppet code and send patches upstream.
First, don’t use hyphens in class names. While hyphens are legal in class names, they are not allowed in qualified variables, thus variables defined within hyphen-named classes are inaccessible from the outside world.
Second, and this one is both tricky and important, Puppet handles prerequisites for definitions by silently passing those prerequisites on to all of the resources within the definitions. Definitions, in effect, don’t really have their own prerequisites, they just pass them on to their children. But – and here’s the problem – if those child resources declare their own prerequisites, those prerequisites will overwrite the passed-on prerequisites, effectively causing them to be ignored.
This problem bit me hard when trying to create a definition for installing Ruby Gems from a local cache of gems:
define local_gem($gem) {
$path = "/var/local/local-gems/$gem"
file { $path:
ensure => present,
source => "puppet://puppet/files/gems/$gem",
require => File["local-gems-dir"],
owner => root,
group => root,
mode => 0664,
}
package { $title:
ensure => installed,
provider => "gem",
require => [ Package["rubygems"], File[$path] ],
source => $path,
}
}
The intent was to be able to declare a local gem like so:
local_gem { "sqlite3-ruby":
gem => "sqlite3-ruby-1.2.1.gem",
require => Package["sqlite-devel"]
}
Thus the “sqlite3-ruby” local gem has the single prerequisite of the “sqlite-devel” package – or at least that’s what I expected. What happened on deployment was that the prerequisite was ignored because when it was passed on to the inner file and package resources, those resources had their own require parameters, and those parameters overwrote the passed-on prerequisite.
The work-around is somewhat hacky. I augmented the definition with a do-nothing resource that has no require parameter of its own. This resource does nothing but capture the passed-on prerequisites. Then I made all of the other resources in the definition include the do-nothing resource as one of their prerequisites. Thus they are made to inherit the passed-on prerequisites.
My final definition looks like this:
define local_gem($gem) {
# dummy exec to propagate requires from local_gem
exec { $name: command => "/bin/true" }
$path = "/var/local/local-gems/$gem"
file { $path:
ensure => present,
source => "puppet://puppet/files/gems/$gem",
require => [ Exec[$name], File["local-gems-dir"] ],
owner => root,
group => root,
mode => 0664,
}
package { $title:
ensure => installed,
provider => "gem",
require => [ Exec[$name], Package["rubygems"], File[$path] ],
source => $path,
}
}
Notice how the file and package resource both require the dummy exec resource. That’s the trick that allows them to require the prerequisites passed on from the local_gem definition.
It’s not pretty, but it works. See this email on the puppet-users mailing list for more on the problem.
Posted in sysadmin
Tags gems, manifests, puppet, rails
2 comments
no trackbacks
Posted by Tom Moertel Fri, 02 Nov 2007 19:32:00 GMT
I recently got a Palm Centro smartphone, and so far I love it. Like most modern cell phones, it has a built-in camera and takes decent snapshots and even records short movies. It’s great for spur-of-the-moment shots when I don’t have my real camera. The trick – and there’s always a trick when it comes to cell phones – is getting the photos off the camera and onto my computer.
To get at my pictures, Sprint would prefer that I sign up for their ludicrously expensive “PictureMail” service. Leave it to weasely telecom execs to come up with another way to squeeze money from teenagers: charge them $5 each month for the “privilege” of sharing their pictures with friends. This fee, of course, is in addition to the fee for “unlimited” mobile Internet use. I guess picture bits are somehow more expensive to move over the air than other kinds of bits.
In any case, my next goal after getting my Centro to hotsync with my Linux workstation was to figure out how to download my photos and movies.
After a bit of hacking, I figured out that the Centro stores images in a typical digital-camera-image (DCIM) hierarchy. For example, I have a 4-GB microSD card installed in my Centro, and I store my photos in the “Palm” album on it. This album ends up stored in the /DCIM/Palm directory on the card.
Using the pilot-xfer program from the pilot-link project, I was able to find the directory and its contents. The trick was to use the sparsely documented –D flag to work with the Centro’s virtual filesystem. Here, for example, is how I list the contents of the Palm album:
$ pilot-xfer -p usb: -D /DCIM/Palm -l
Listening for incoming connection on usb:... connected!
Directory of /DCIM/Palm...
652 Fri Nov 2 08:17:06 2007 Album.db
292053 Fri Nov 2 09:04:20 2007 Photo_110207_001.jpg
78493 Fri Nov 2 08:17:06 2007 Video_110207_001.3g2
20 Wed Oct 31 12:09:20 2007 Thumbnail.db
Thank you for using pilot-link.
Here, you can see that I have one photo and one movie in the album. (Movies are stored in .3g2 files that contain MPEG4 video.)
To download the files, I again turned to pilot-xfer, this time using the –f (fetch) flag to fetch a list of files. Here, for example, I’ll fetch the image from the listing above:
$ pilot-xfer -p usb: -D /DCIM/Palm -f Photo_110207_001.jpg
Listening for incoming connection on usb:... connected!
Fetching '/DCIM/Palm' ... (292053 bytes) 285 KiB total.
Thank you for using pilot-link.
So that’s the process. It’s kind of clunky, so I wrote a small Python program to automate it. (I’m learning Python. If you’re a Pythonista, please consider critiquing my code. I would be especially thankful if you could point out any helpful idioms that I may have overlooked.)
Here’s how to use the program:
$ get-pilot-photos.py --help
Usage: get-pilot-photos.py [options]
Options:
-h, --help show this help message and exit
-s SRCDIR, --srcdir=SRCDIR
VFS dir on Palm device from which to fetch images
-d DESTDIR, --destdir=DESTDIR
Where to save the images on your computer
Both the —srcdir and —dstdir options are optional. If you omit the first, the program will download photos and movies from the /DCIM/Palm album. If you omit the second, the program will save the downloads to a new, timestamped directory within your home directory.
That’s it. The code is below.
Read more...Posted in hacks
Tags centro, download, hotsync, images, movies, palm, python
15 comments
no trackbacks
readers