Insect Art: The quest for awesome

I’m always on the lookout for well made, beautiful insect art. Not just pinned insects in a box (as showcased in many an entomologist’s office and home), nor the pseudoscientific version of “look! Bugs are pretty when they have wings and don’t bite!” type of thing. No…I’m more looking for a cross between scientific names and jewel-toned elytra; between the beauty in an ant colony and the beauty of a damselfly’s flight patterns. Enter RealButterflyGifts, a brick-and-mortar store out of South Dakota that now has an extensive shop on Etsy.

Not only do they have fine quality, beautifully curated insects, but they add in the element of art to their presentations. I’ve added some of the interesting products below, but have yet to go through the entire inventory. There goes my afternoon!

Isn't this amazing?
I like this style

They have a whole series of butterflies/other insects displayed with maps of their countries of origin. I love the idea of a grouping of these as a centerpiece in an office or library.

Aren't they the cutest?!

Look at the pretty!

Another lovely art piece

This is a great way to bring real insects into any decor without overwhelming those who think it’s gross.

Not quite my style, but....

Now while I wouldn’t have *personally* gone with a butterfly (I’d have preferred a group of ants, or a spread of brightly colored beetles) I love love love the idea of giving an art piece like this as a wedding memento. It might even work as a wedding favor for very small groups. Maybe I’ll have to put one together for my upcoming anniversary.

Dragonfly on print

This is another series this store does–taking art prints and adding a touch of reality with insects. They also do this with vintage botanical prints.

Love it!

It’s not just the “pretty” insects that get the royal treatment at this store, either. This is a velvet ant. Love it!

New. Favorite. Store.

How can you not love a store that sells mounted cockroaches? Granted, the title calls it a beetle at first, but then it explains. Cockroachs!

Pretty!

I just really like this butterfly.

I’m afraid I’m going to have to hide my credit cards.

–Adrienne

Mapping Firefox & Thunderbird Behaviors to Preference Settings

Thunderbird settings

Individual in the Enterprise

Firefox, Thunderbird have full-fledged graphical settings editors.  It is easy for a user to change the behavior of his or her web browser with a few mouse clicks.  While this approach is sensible for the home user, GUIs hamper software configuration in the corporate enterprise.  Although Mozilla products textually represent preferences in a flat file, discovering the right text and value is not always simple.  I will outline some techniques I use to determine preference strings for a given behavior.

Preferences in Mission Control Desktop

Mozilla MCD autoconfig is an invaluable tool to the software administrator.  It runs at browser startup setting preferences according to corporate policy.  After starting, Firefox saves all settings to the user’s local prefs.js file.  The autoconfig API and user  prefs.js work with text preferences.  When you decide to change the application’s behavior your prefs.js is a good place to look.

Start clean

Quit Firefox.  Backup then remove your Firefox profile directory. On linux it is in $HOME/.mozilla/firefox. Then launch the browser starting with a good autoconfigured profile.

Compare

Take a backup of your user prefs.js from Firefox”s profile directory. ($HOME/.mozilla/firefox//prefs.js)  Make the behavior change and apply.  Use diff to compare the preference files.

An example

Suppose your company decides that Firefox should only keep third-party cookies for the lifetime of the browser.  Once the user closes Firefox, it will delete all third-party cookies.  Make the change (for version 3.6.3) in Settings –> Privacy –> Check Accept cookies from sites, then check Accept third-party cookies and change the dropdown to Keep until: I close Firefox.

Your preferences should look something like this:

0 apollo firefox/kzssiknu.default % diff -u prefs.js.pre prefs.js
--- prefs.js.pre    2010-04-22 12:57:30.000000000 -0500
+++ prefs.js        2010-04-22 12:57:39.000000000 -0500
@@ -230,6 +230,7 @@
 user_pref("lightweightThemes.persisted.footerURL", true);
 user_pref("lightweightThemes.persisted.headerURL", true);
 user_pref("metrics.upload.enable", false);
+user_pref("network.cookie.lifetimePolicy", 2);
 user_pref("network.cookie.prefsMigrated", true);
 user_pref("nglayout.debug.disable_xul_cache", true);
 user_pref("nglayout.debug.disable_xul_fastload", true);

See that a new preference called network.cookie.lifetimePolicy was inserted with value 2.  Use these in autoconfig, calling

// Remember third-party cookies until the browser closes
lockPref("network.cookie.lifetimePolicy", 2);

Sometimes it’s not that easy

The above method does not work all the time.  For example, Thunderbird’s password settings are not so obvious.  My company does not allow password storage so I needed to lock out that behavior.
Save Passwords

Inspecting the preferences GUI leads nowhere.  My first resource in these cases is the About:config_entries page on MozillaZine.  It’s a wild wiki page containing mostly-complete setting documentation for all the Mozilla products.  There you will find a table with the right information.

Name Type Meaning of Values
signon. rememberSignons Boolean True: (default): Enable the Password Manager
False Opposite of the above

The About:config_entries page also has pointers to the wiki’s Category:Preferences and The Preferential Project.  Each page has something the others lack.  When these resources fail, I sign on to irc.mozilla.org (as OccamRazor, old-school IRC etiquette rules apply.) or as a last resort, hit a search engine.

Document it

When you find the right text to twiddle document the behavior in your autoconfig as I did for the cookie lifetime above.

LDAP Queries in Mission Control Desktop

Previously, we saw that Mozilla MCD can inspect a user’s environment using getEnv().  It can also retrieve information from an LDAP directory.  I use this feature to inform Firefox and Thunderbird of the user in detail.  The corporate directory knows the user’s full name, mail server and authentication credentials.  autoconfig takes this and, among other useful things, constructs an email account for Thunderbird without user intervention.

The javascript API to deal with LDAP is a bit hackish, however it is all we have.  The first task is to define a function called processLDAPValues() which accepts a queryResults string as its only argument.  Inside processLDAPValues you extract return data from queryResults.

Instead of invoking processLDAPValues() directly, you call getLDAPAttributes() which in turn gets you to your function.  To illustrate, here is the code I use to query the corporate directory server and save the values for later use.

var userInfo = new Object();  // This will hold LDAP results
 
userInfo.envUser = getenv("LOGNAME");   // Unix UID
userInfo.envHome = getenv("HOME");      // User home directory
 
var ldapHost = "ldap.example.com";
var ldapBase = "dc=example,dc=com";
 
if( userInfo.envUser )
{  var ldapFilter = "uid=" + userInfo.envUser;  }
else
{  throw("Couldn't get UID from the environment");  }
 
// LDAP attributes to retrieve from the server
var ldapAttrs = new Array( "cn", "email", "employeenumber", "givenname", "mailhost", "sn", "uid" );
 
// Define how to process LDAP results before we make the call
function processLDAPValues(queryResults)
{  if( queryResults )
   {  // Build the userInfo object for later use
      for( var attr in ldapAttrs )
      {  userInfo[ ldapAttrs[attr] ] = getLDAPValue( queryResults, ldapAttrs[attr] );  }
   } else
   {  throw( "No LDAP results" );  }
}
 
// Call upon LDAP for the values in ldapAttrs array
// Uses the previous processLDAPValues()
getLDAPAttributes( ldapHost, ldapBase, ldapFilter, ldapAttrs.join(",") );

The first thing I do is create a userInfo object that will hold LDAP results for use later in the autoconfig.  To that object I add attributes for the user’s login name and home directory.

The next bit sets variables to contain the directory server’s hostname, base DN and the LDAP filter to use in the search. It’s a good idea to throw an error if there is no $LOGNAME.  (In a later post I will show how to enhance autoconfig error reporting.)

The ldapAttrs array names the attributes I want to return from LDAP.  Change this array to suit your environment.  The last line of code joins the array together with commas and feeds it to getLDAPAttributes along with the hostname, base DN and filter.  getLDAPAttributes is defined in MOZILLA_HOME/defaults/autoconfig/prefcalls.js and does the work to perform the query, then call your predefined processLDAPValues() function.

The example autoconfig script at developer.mozilla.org set preferences inside processLDAPValues, however this is a bad convention.  There are many preferences that require user information and separating pref() calls away from the main block of preference setting can be confusing.  As you can see here I simply run through the array of attributes I’m interested in and get the result from the LDAP query for that attribute, assigning it to the userInfo object.

Later on in the script I ask the userInfo object for those stored LDAP attributes. To set the hostname of the user’s mail server, for example, I call

// IMAP server name from corporate LDAP directory
defaultPref("mail.server.server1.hostname", userInfo.mailhost );

LDAP directories are a great resource. What attributes could you store in your corporate server?

Setting User Preferences with Mission Control Desktop

A challenge with software

Managing software for thousands of users presents a formidable challenge to the system administrator. Publishing corporate policy, using standard environments and providing clear end-user documentation helps. However, it doesn’t beat automatically doing it right.  This is the power of MCD autoconfig.

In an earlier post, I introduced MCD as a way to configure Mozilla products (Firefox, Thunderbird, Prism, etc) and provided background on building them with autoconfig support.  This post covers how to get started with the standard javascript API.  In forthcoming posts I’ll detail the useful enhancements I built using this API.

The environment

First, a quick rehash of my world.  I work in a Solaris shop with over 33,000 users.  Supported users log into a shared Sun Ray server or their personal workstation which mounts a shared NFS directory.  That directory houses the software I support along with about 700 other programs.

While this post is unix-centric, other operating environments that launch managed software can make use of MCD. See the introductory post for  a little more detail.

Mozilla Preference System

Firefox and Thunderbird use a simple preference tree to store all configuration options. Leaves of the tree are strings that store the option’s value.  For example, the preference browser.startup.homepage is a string containing the URL(s) of Firefox’s homepage.  mail.forward_message_mode contains an integer indicating how Thunderbird should forward email messages (inline or as an attachment).  You can find every available setting and their values in the config editor for Thunderbird and about:config in Firefox.

When a user changes his or her preferences the changed values are stored in a file called prefs.js in their home directory. On my MacOS laptop, this is $HOME/Library/Application Support/Firefox/Profiles/kzssiknu.default.

The Application Programming Interface

The autoconfig acts on preferences through a javascript API defined in the file MOZILLA_LIB_DIR/defaults/autoconfig/prefcalls.js.  I will talk about the most useful in this post and cover the LDAP parts of the API later.

// Used most often
function defaultPref(prefName, value);
function lockPref(prefName, value);
// Sometimes used
function displayError(funcname, message);
function getenv(name);

defaultPref() and lockPref()

These two functions perform the bulk of work in an autoconfig script.  A default preference setting may be overridden by the user, but a locked preference may not.

getenv() and displayError()

getenv() acts as you would expect from its name. This function returns the value of an environment variable.  I use it to get $USER and $HOME. displayError() pops up an error message.  It is useful for debugging, but a user should rarely see it.

Putting it all together

We now have some basic building blocks to configure thousands of users. Here is a look at a simple autoconfig.js file for Firefox.  These settings will apply to every user.

// Catch errors
try
{
   // Set  downloads directory to a folder on the user's desktop
   var download_dir = getenv("HOME") + "/Desktop/Downloads";
   defaultPref("browser.download.defaultFolder", download_dir);
   defaultPref("browser.download.dir", download_dir);
   defaultPref("browser.download.downloadDir", download_dir);
   defaultPref("browser.download.folderList", 2);kk
 
   // Length of Time to Remember Visited Pages For (Days) - 30
   defaultPref("browser.history_expire_days", 30);
 
   // Automatically Add 'www.' and '.com' to the Location if a Web Page is Not Found - Enabled
   defaultPref("browser.fixup.alternate.enabled", true);
 
   // Lock the cache size to 60MB for shared performance
   lockPref("browser.cache.memory.capacity", 60000);
   lockPref("browser.cache.disk.capacity", 60000);
 
   // fix memory usage with lots of tabs
   lockPref("browser.sessionhistory.max_total_viewers", 2);
 
   // Set animated images to loop once
   defaultPref("image.animation_mode", "once");
 
} catch(e)
{
   displayError("autoconfig.js failed", e);
}

Learning preference strings

Finding the right preference setting or combination of preferences that change the program’s behavior sometimes presents a challenge.  I use the About:config entries page on the Mozilla Zine knowledge base.  That page also has a pointer to three more resources.

Another technique is to watch your own prefs.js file for changes when you twiddle settings.  Save a copy of prefs.js before flipping a preference.  Immediately quit the application after the change and diff the two files.

[Edit: I wrote up an entire post on this subject.]

Using LDAP and more fun things to do

In following posts I will cover retrieving information from LDAP, better error reporting, reading local files like $HOME/.printers, and simplifying Thunderbird email account management. Stay tuned.

An Introduction To Mission Control Desktop

What is MCD?

MCD (aka AutoConfig) is a script used to programmatically configure Mozilla products such as Firefox and Thunderbird in the enterprise for multiple users.  Part of my job is to ensure 33,385 people have the right settings to check their email and browse the web.  Centralizing their set up with autoconfig removes the burden from the user.

Why write about it?

Documentation on MCD is old, but not exactly out of date.  The basics of autoconfig have not changed since the age of the Netscape browser.  From trolling newsgroups, IRC and Google, I know many people use MCD, but share little about the subject. (Some do.)  Over the course of my work I wrote object prototypes, extended error reporting and generally tried to make using this bit of javascript easier. I want to reach out to the community and give a little back.

A quick run-through

Most people think of javascript as a browser technology. But, MCD has access to XPCOM, a bridge between C++ libraries and javascript, which gives the developer power to poke at Mozilla internals.  When Thunderbird (Firefox, Seamonkey, etc) launches, it executes a javascript script that makes use of a configuration API.

The autoconfig sets preferences exactly as a user would using about:config. It can also render preferences immutable, locking them down according to corporate policy.  When I inherited the script it was  simply a long string of preference directives with a little LDAP voodoo.

defaultPref("news.server_change_xaction", 0 );
defaultPref("mail.migration.copyMailFiles", false);
defaultPref("network.cookie.disableCookieForMailNews", false);
   lockPref("mail.remember_password", false);
defaultPref("javascript.allow.mailnews", false);
defaultPref("mail.addr_book.lastnamefirst", 1);
defaultPref("mail.toolbars.showbutton.file", false);
defaultPref("mail.toolbars.showbutton.junk", true);
defaultPref("mail.forward_message_mode", 2);
defaultPref("mailnews.wraplength", 72);
defaultPref("mail.wrap_long_lines", true);
defaultPref("mail.collect_email_address_outgoing", true);
defaultPref("mail.collect_email_address_incoming", true);

Not the easiest thing to grok.

After Thunderbird executes the autoconfig it starts up normally, applying saved user preferences. defaultPref settings are overridden by user preferences, but lockPref are not.

If you want to turn on a proxy server and force SSL in Firefox for every user it becomes easy to do:

// Set http proxy to your.server.domain
lockPref("network.proxy.http", "your.server.domain");
// Require and lock SSL
lockPref("network.proxy.ssl", true);

Details, implementation details

There are a number of things required to get MCD working.

Build *zilla (Firefox, Thunderbird, etc) with support

Your Mozilla product needs to be built with pref extension support. Add this to your .mozconfig file:

ac_add_options --enable-extensions=pref

To utilize LDAP (you do want to use LDAP, don’t you?) check the configure script for:

MOZ_LDAP_XPCOM=1

You can check about:buildconfig in Firefox to see if your build is good to go. While MCD documentation is sparse, the Mozilla Developer’s Center has plenty of build instructions.

Software distribution

I work in a Solaris world. Servers and desktops mount a shared NFS directory from a network of servers housing some 735 programs, including Firefox & Thunderbird.  The directory is mounted read-only so average users are not tempted to twiddle with the software.  Although I wrote this paper from a unix perspective the implementation will work in a Linux, Windows, or MacOS environment.  Mounting a shared software repository makes the system robust, however MCD works in a network of stand-alone desktops.

Breaking .cfg “encryption”

*zilla products first read a javascript configuration file in the lib directory called, for example, firefox.cfg.  In the beginning-time, Mozilla developers chose to ROT-7 encode the file, obscuring its contents from users.  When Netscape 7 came out, they did away with ROT-7 in favor of ROT-13. Many Firefox and Thunderbird .cfg files are still encoded this way using moz_byteshift.pl.

The rotary encoding is controlled by a setting in $MOZ_LIB_DIR/greprefs/all.js. At packaging time I patch this file, setting encoding to 0.

// ROT-encoding is bad, mmmkay?
pref("general.config.obscure_value", 0);  // for MCD .cfg files

This tells *zilla not to ROT-decode the .cfg file.

This shadowy file mojo likely came from the day of stand-alone workstations where users had root access and the software maintainers wanted to have just a little control over Netscape preferences.  Hiding the configuration file’s location gives you the illusion of control.

Now, the .cfg file is on a read-only mounted partition and nobody on the system has super-user level access. There is little danger of a user skirting corporate policy by turning off autoconfig.

Pointing *zilla at the autoconfig

When Firefox starts up it checks for and executes javascript a .cfg file giving it the autoconfig script’s path.

// $MOZ_LIB_DIR/firefox.cfg
// the output from the obscuration is still more readable than MORK!
lockPref("autoadmin.global_config_url","file:///path/to/firefox,v3.0.17/share/autoconfig.js");
lockPref("autoadmin.offline_failover", true);
lockPref("autoadmin.refresh_interval", 60);

I left the MORK comment line in there to remind me how far we’ve come already.

These directives:

  • Set the autoconfig url
  • Tell *zilla to automatically fail over to offline mode if online browsing fails
  • Re-fetch the autoconfig file every 60 minutes

Any URL *zilla understands is a valid value for autoadmin.global_config_url meaning you could house the autoconfig script on a web server.

Away you go

Now your Mozilla product will read and execute the javascript autoconfig script you indicated.  There you can set or lock application preferences using a specialized XPCOM API.  I will cover the API in a following post.

Barrelling Day


All those fermenting vessels under the looming Merlot barrel contain Russian Imperial Stout. Yesterday the TAbc drained the beer into that barrel to condition over the summer. The first task of the day was to sanitize the barrel with 20 gallons of boiling water.






The barrel sits high on its rack making gravity transfer tricky. The duck-in cooler gave us the necessary height.


Surprisingly little beer spilled, but what did come out flew across the room, landing on Ruth.

After a long day of barreling, the beer came to rest in my cold room, where it will sit until we bottle it in October.


I bottled a 12-pack pre-barrel for comparison.

Alt Two

My second try at an Altbier turned out better than the first. Alt One got an infection from the MiniBrew plastic conicals I was using. A tragedy, because it tasted so good coming out of the kettle.

Alt Two is not my own recipe, but a concoction from Jamil Zainasheff’s Brewing Classic Styles. Scaled up to 10 gallons the recipe is:

Fermentables

  • 18 lbs Pilsner
  • 2 lbs Munich
  • 0.5 lbs Debittered Black malt
  • 0.5 lbs Caramunich 60L
  • 6 oz Pale Chocolate malt 200L

Mashed starting at 151º, falling to 145ºF over the course of 60 minutes. (Need winter insulation for my mash tun.) Mash out at 160ºF. Sparge. Collected 12.5 gallons 11% B sweet wort. Boil 90 minutes.

Hops

  • 2.5 oz 8.1% AA Perle 60 minutes

Fermentation

Pitch a 1600ml starter of WLP 029 German Ale yeast into 14.3% B original gravity wort.

Fermented two weeks between 58º & 66ºF. Lagered for 26 days.

Notes

  • 2010-02-15 9.6%B Vinous notes
  • 2010-03-13 8%B Vinous flavors reduced. Ready to package.

It pours a deep copper brown with no appreciable head. Carbonation has not quite developed and I expect to get a good stand of foam in a few more days under pressure. There is roastyness up front and that vinous flavor refuses to disappear completely. This Alt puckers the mouth just a little, a problem attribute to poor scaling of the recipe from 5 to 10 gallons. The percentage of dark roasted malts may be too high. Bitterness is present and polite as appropriate for this malt-centric beer.

For my third Altbier I will find a common ground between One and Two. Not so much roasted malt as #2 and not so much Munich or Vienna as #1.

Tasting & Bottling Something Else

It is 14.6° Plato and Something Else is three weeks old. Starting at 25.2º P, the big gravity beer weighs in at a small 6.2% ABV. Before putting it all away for conditioning a little evaluation is in order.

There is a little ester in the nose. No hop aroma. The uncarbonated beer is sweet, bitter, roasty, “stout-like”, and lacks much fermentation character. Tastes a little like an over-hopped milk stout might. It sticks to your mouth.

It is close enough to be a Russian Imperial Stout, but lacks nuance due to the simplistic grainbill.

I have about 80 fluid ounces to bottle. The small volume batch is a breeze to work with. Next time I will remember to add priming sugar. Not to worry, the gravity is still drifting downward.

The Domestic & Something Else

Read from the bottom up:

twitter feedToday I brewed The Domestic for a second time. It is a Classic American Pilsner, also called a Pre-Prohibition Lager. The recipe is from Jamil Zainasheff’s book Brewing Classic Styles.

  • 12.5º Plato OG
  • 80% German Pilsner
  • 20% Flaked Maize
  • Rest at 148ºF for 60 minutes
  • Mash out to 160ºF
  • Collect 11.5 gllons
  • 2 oz 8.1% AA Perle FWH
  • 0.5 oz 3.8% AA Czech Saaz 30 mins
  • 1 oz 3.8% Czech Saaz 10 mins

I recently started doing a mash-out and this is my second brew session doing so. Combined with a slow sparge, I saw improved efficiency the first time. Today I ran into problems.

My mash tun is direct-fired and I recirculate the wort to prevent scorching. During vorlauf today my flow rate slowed to a trickle. Most of the time the March pump loses prime and I goose it a little to get it going again. When that didn’t work I stirred the grainbed and restarted the vorlauf. None of the usual tricks got the wort flowing again. But this was no ordinary problem.


That piece of hose pokes through the mash tun’s false bottom, acting as the pick-up. Heat from the burner melted it partially closed. Wort in the bottom of my tun scorched from lack of movement.


The sparge marched onward and I collected 11.5 gallons of sweet wort. I measured the gravity at 9.6º Plato, or 1.038. At that strength my post-boil gravity comes out to 1.043; 7 points too low. Reducing the volume to hit the gravity posed two problems. First, the style demands a light-colored beer and a prolonged boil would darken it too much. Secondly, the first hops were in the kettle and would throw off the bitterness balance. I cursed a little, tweeted then pushed on.

Ninety minutes later the brew was boiled then chilled and in the fermenter. When I lowered it into the converted chest freezer the bulges of the keg would not fit. Previously, I had tried to put the keg in the freezer with the same result, so I should have known. I grumbled a little.


It is now in my ale fermentation cooler, turned up to full blast cooling. When it comes time to lager this baby, I’ll split it into two carboys and put them in the freezer. Notice I hit my target starting gravity of 12.5º B.

After collecting the desired pre-boil volume I became curious how much wort I had left in the mash. Opening the spigot on the tun I dumped 6 liters of 9.6º B pale sweet wort into a bucket. With everything that went wrong today I was not about to waste so much potential beer.

Looking at my grain store, I picked an additional 2 lbs Crystal 60ºL and one ounce of chocolate malt. Approximating the recipe gives this:

  • 2 lbs German Pilsner
  • 2 lbs Crystal 60º L
  • 1 oz Chocolate

Post-boil volume would be less than a gallon

  • 0.3 oz 9.1% AA Centennial 60 mins
  • 0.5 oz 9.1% AA Centennial 15 mins
  • 0.5 oz 4.5% AA Fuggles 10 mins
  • 0.5 oz 4.5 %AA Fuggles 1 min


The final gravity turned out to be 25.2º P (1.107). It will probably be an Imperial Stout-ish. The yeast is a German ale/kölsh strain coming right out of an Altbier I put into lager tonight. Hope it can handle high gravity.

As an aside, I am quite fond of the brew-in-a-bag method those Aussies invented. Tonight’s second brew session was essentially that.

Things Adrienne & Dean Do, Think and Write