Well Droid, you take crummy pictures. Sadly, you’re all I have.

Fortunately, I’m giving you a third option. Easy to follow instructions.

Required Packages

• ecryptfs-utils
• libecryptfs0

Assumptions

I assume that you have a working ubuntu system and a hard drive mounted at /media/hd with an encrypted user folder then being at /media/hd/home/user (relative to the current, working system).

In the example below, I’m mounting the decrypted files at /media/myfiles, though you can obviously change this out. Additionally, if your home partition is separate from the root partition, the paths would need to be changed accordingly. Hopefully it’s obvious where those changes would need to be.

All of these commands need to be executed as root. I encourage a sudo -s session to work in.

Recover the Mount Passphrase

Your login password is not the passphrase to the encrypted data. To get the actual mount passphrase we must “unwrap” it.

1. ecryptfs-unwrap-passphrase /media/hd/home/.ecryptfs/user/.ecryptfs/wrapped-passphrase

2. [enter your login password]
3. A “passphrase” will be printed to the screen.
   This is your mount passphrase.

Recover Filename Encryption Key (FNEK)

1. ecryptfs-add-passphrase --fnek

2. [enter your mount passphrase]
3. Two lines will print out. You want the signature from the second line.
   This is your FNEK signature.

Mount the Encrypted Files

1. mount -t ecryptfs /media/hd/home/.ecryptfs/user/.Private /media/myfiles

2. Passphrase: (paste your mount passphrase from above)
3. Selection [aes]: 1 (or whatever the aes option is)
4. Selection [16]: 1 (or whatever the 16 option is)
5. Enable plaintext passthrough (y/n) [n]: n
6. Enable filename encryption (y/n) [n]: y
7. Filename Encryption Key (FNEK) Signature []: (paste the your FNEK signature from above)
8. Ignore the error message and handle the signature logging however you like.

Needed:

• VirtualBox – free
• Empire EFI – free
• Retail Mac OS X 10.6 – $30

Total Cost: $30

Steps:

1. Create a new Virtual Machine.
   Mac OS X Server 64 bit
   20GB at least
2. Specify one of the Empire EFI images as your CD image.
   Boot from it.
3. Wait till you see the Empire EFI screen.
   Wait 20 seconds.
4. Switch to your Snow Leopard disc.
5. Wait 20 seconds. Press F5.
   Hit enter to boot the Snow Leopard entry.
6. Install.
   You may need to format your disk first with Disk Utility.
7. Continue to use the EmpireEFI disc to boot your virtual machine.

Enjoy. Wasn’t that simple?

A quick look at the Google Calendar API documentation makes it obvious that the PHP examples solely use the Zend_Gdata library and provide no examples of making manual queries outside of the convenience functions provided by Zend_Gdata_Calendar. Fortunately, Eric was able to find an example of the XML necessary to make a calendar public through the API.

Ultimately, there were three problems that we ran into when attempting to get Google Calendar to accept our delicious XML.

First, a misconception about Zend’s Gdata classes. The code began with a simple call to Zend_Gdata_ClientLogin::getHttpClient($user, $pass, $service); which returns a Zend_Gdata_HttpClient (authenticated through ClientLogin) object which is a descendant of Zend_HttpClient.

I assumed that the Zend_Gdata_HttpClient would have an easy method for POSTing or GETing to/from the Calendar Data API, but alas Zend has not blessed the PHP-using world with such ease.

Second, I assumed that the creation of Zend_Gdata_HttpClient would at least allow us to send a request with the authentication details added automatically. After repeatedly getting authentication errors, it became clear that this was not the case (and later, upon inspection of the code in the Gdata classes that call the request() function of Zend_HttpClient, it was apparent that they were adding the auth details for each request).

Third, I made the silly assumption that receiving 302 responses indicated that we still had a problem. As it turns out, simply reading the documentation would have revealed that that is not the case:

Just like in the previous example, Calendar may return an HTTP 302 redirect; if so, then the redirect URL has a new parameter, gsessionid, appended to it. If you received the redirect, then send the same POST request again, with the same Authorization header and the same content, but with the gsessionid parameter appended. The response may also include a S cookie, which you should store and send this cookie with future requests as appropriate. Please see the knowledge base for more information on handling sessions with the Calendar Data API. Please note: if a session ID indicated in a cookie header conflicts with the session ID passed as a gsessionid URL parameter, you will get caught in a redirect loop.

Ultimately it resulted in a nice wrapper function that I wrote:

function gdata_xml_request($client, $request_uri, $xml, $method='POST', $redirs=3) {
  $auth_string = "GoogleLogin auth=" . $client->getClientLoginToken();
  $client->setHeaders("Content-Type", "application/atom+xml");
  $client->setHeaders("Authorization", $auth_string);
  $client->setUri($request_uri);
  $client->setRawData($xml);

  $response = $client->request($method);
  if($response->isRedirect() && $response->getStatus() != '304' && $redirs-- > 0) {
    $client->setUri( $response->getHeader("Location") );
    $response = $client->request($method);
  }

  return $response;
}

For the example of publicizing a calendar (identified by $cal_id), the following code would be used:

$client = getClient();
$request_uri = "http://www.google.com/calendar/feeds/" . $cal_id . "/acl/full";
$xml = <<<EOF
<entry xmlns='http://www.w3.org/2005/Atom' xmlns:gAcl='http://schemas.google.com/acl/2007'>
  <category scheme='http://schemas.google.com/g/2005#kind' term='http://schemas.google.com/acl/2007#accessRule'/>
  <gAcl:scope type='default'></gAcl:scope>
  <gAcl:role value='http://schemas.google.com/gCal/2005#read'></gAcl:role>
</entry>
EOF;
$response = gdata_xml_request($client, $request_uri, $xml, 'POST', 3);

If you like, you can see this in action and the source.
The 409 Version Conflict indicates that there is already an ACL entry that matches the request (aka, the calendar is already public).

Clearly, WordPress is not being very cooperative about this whole “wanting to post code” business. Not being able to insert tabs, spaces, or utilize a monospaced font made writing this quite annoying. That and the fact that Ubuntu refuses to disable the touchpad while I’m typing, so everytime my palm touches this huge annoying … thing, it selects text in the box and I overwrite it. For example, this sentence and the one before has required 4 Ctrl+Z’s to undo overwriting mistakes from my palm. >_< Resolving this is my next goal.