Before Josie was born we set up a blog for her. The intent was for Angela and I to record Josie's early years in a fun way, without all the tedium of a traditional scrapbook. We wanted it to be low effort, high reward. We selected Posterous as the platform for Josie's blog, since it offered a decent product for zero cost and very little effort.
Posterous offered some great features for us: it supported dead-simple post-by-email and offered robust media management. The former meant that we could post to Josie's blog just about anywhere simply by firing off an email from our phones. Lots of other blog platforms support post-by-email, too, but Posterous's seemed to be so well baked in as to require no effort from us. Posterous also offers a decent -- though far from great -- application for both iOS and Android, so any kind of complicated post we might want to create could be done with that, too.
Where Posterous really shines, though, is media handling. Photos and videos attached to emails sent to Posterous show up automatically. No fussing with selecting sizes or transcoding videos. In the event that multiple photos are attached to a single post, Posterous generates a nifty little photo gallery automatically. It's super easy for us, the content creators, and extremely useful to all our family and friends who visit Josie's blog.
We'd been relatively happy with Posterous for the past two and a half years. But all good things come to an end. Two factors have driven me to migrate away from Posterous. Frist, Posterous was bought by Twitter. While Twitter hadn't mucked up Posterous much since the acquisition, they hadn't done much to make it a lot better than it was, either. Also, Posterous is shutting down. So there's that. The second big issue is that I finally realized that all our Posterous-hosted media lived off on its own, isolated from all the other media silos we use.
This last bit is the really important bit. I have a slowly growing collection of photos at Google, thanks to the confluence of Google+, Picasa, and Android Instant Upload. But I've also had a Flickr account since 2005, with more than nine thousand photos and videos. This represents the bulk of my digital life. To have another, separate, isolated repository of photos over at Posterous just didn't make sense.
Nor does it make sense to manually upload photos to both Flickr and Posterous. Sure, I could do something crazy with IFTTT, but that's just introducing more complexity by requiring that I create and maintain yet another account somewhere out in the cloud.
So I've spent the last couple of weeks updating the Habari post-by-email plugin to support pluggable storage mechanisms. I then wrote a Flickr storage plugin for PBEM that sends any email attachments to Flickr. This works a treat, thus far.
To make this all work, I've created a new email address for Josie's blog, and configured the PBEM plugin to check that account. Angela and I are whitelisted senders, so any emails we send to that account will appear as blog posts on Josie's blog. Any media attachments we include on our emails will be sent to Flickr, and embedded in the resultant post. This gives us all the benefits of Posterous with the added benefit that all of our photos and videos of Josie's life are part of my Flickr archive automatically.
When I first heard about OpenShift, I was underwhelmed. Hosting accounts aren't that hard to find or set up, so the whole Platform-as-a-Service initiative struck me as a solution looking for a problem. But the more I poked around, the more I realized that this was a pretty great offering for developers. I'm not a developer by trade or training, so the obvious utility of PaaS slipped past me at first. As a sysadmin, I'm much more interested in the L and A portions of the LAMP stack than I am in the P. :)
Red Hat has a guide on how to create an OpenShift quickstart for hosted applications. Notably absent from the list of extant quickstart apps was Habari, so I decided to remedy that! Here are my notes for what I did.
First, obviously, I needed to create an OpenShift account. After creating my account, I published my ssh public key to my account. Creating an OpenShift account creates a domain in which your apps will run. My account name is "skippy", so my OpenShift domain is also "skippy".
Next I installed the OpenShift client tools:
$ sudo gem install rhc
I tried to create an application:
$ cd ~/code $ rhc-create-app -a habari07 -t php-5.3 -l firstname.lastname@example.org
but got the following error:
/var/lib/gems/1.8/gems/rhc-0.81.14/bin/rhc-create-app:24:in `require': no such file to load -- rhc-common (LoadError) from /var/lib/gems/1.8/gems/rhc-0.81.14/bin/rhc-create-app:24
The solution is to export the RUBYLIB environment variable to my shell:
$ export RUBYLIB=/var/lib/gems/1.8/gems/rhc-0.81.14/lib
I should probably add this to my ~/.bash_profile, but for now I just manually execute this each time I log into my development box.
After that, I was able to create an app:
$ rhc-create-app -a habari07 -t php-5.3 -l email@example.com
Here's the full output from that command:
Password: Found a bug? Post to the forum and we'll get right on it. IRC: #openshift on freenode Forums: https://www.redhat.com/openshift/forums Attempting to create remote application space: habari07 Now your new domain name is being propagated worldwide (this might take a minute)... Pulling new repo down Warning: Permanently added the RSA host key for IP address '22.214.171.124' to the list of known hosts. Confirming application 'habari07' is available Attempt # 1 Success! Your application 'habari07' is now published here: http://habari07-skippy.rhcloud.com/ The remote repository is located here: ssh://firstname.lastname@example.org/~/git/habari07.git/ To make changes to 'habari07', commit to habari07/. Successfully created application: habari07
OpenShift provides some stub files in the /php directory, which we don't need. Remove them:
$ rm -rf habari07/php/*
I then downloaded a zipfile of the Habari 0.7.1 source code, which is the current stable version. I unzipped the archive and copied the Habari source files to the /php directory of my OpenShift app:
$ cp -av habari-0.7.1/* habari07/php
OpenShift deletes the entire contents of your app's /php directory with every git push, which means that the Habari SQLite database needs to live outside of the /php directory. See OpenShift KB-E1002 for details.
To account for this, we need to build support for this in the Habari config.php. Thankfully, OpenShift provides a number of environment variables that describe the OpenShift application. The $_ENV['OPENSHIFT_DATA_DIR'] holds the path to the persistent file storage location for this app. So I created a config.php file in my app's /php directory with the following:
$path = $_ENV['OPENSHIFT_DATA_DIR']; Config::set( 'db_connection', array( 'connection_string'=>"sqlite:$path/habari.db", 'username'=>'', 'password'=>'', 'prefix'=>'' ));
Habari has long supported an unattended installation process, which makes deploying to OpenShift extremely easy. We can define a $blog_data array in the config.php file which will allow Habari to install itself without human intervention. I added the following to config.php:
$blog_data = array( 'blog_title' => 'Habari', 'admin_username' => 'admin', 'admin_pass1' => 'habari', 'admin_pass2' => 'habari', 'admin_email' => 'CHANGE@ME', );
Now I'm ready to add the Habari files and my config.php to the OpenShift repository:
$ cd habari07/php $ git add . $ git commit -a -m 'initial Habari commit' $ git push
I visit http://habari07-skippy.rhcloud.com in my browser and see a ready-to-use Habari blog! I can log in with username "admin" and password "habari". Success!
But that's only half the battle: a personal blog running in OpenShift. What I want is to make a template so that anyone can easily deploy a Habari blog on OpenShift.
Following the quickstart instructions, I created a GitHub repository named habari-07-sqlite-quickstart, and added that as a remote repository:
$ cd ~/code/habari07 $ git remote add github https://email@example.com/skpy/habari-07-sqlite-quickstart.git
I edited the README file, and copied it to README.md (is that part even necessary?) and then added them to version contol:
$ vi README $ cp README README.md $ git add .
Commit these files, and push them up to GitHub:
$ git commit -a -m 'adding README' $ git push -u github master
That's it! Anyone can now follow the instructions in the README file to easily deploy their own Habari installation on OpenShift!
Once deployed, you can assign custom DNS names to your OpenShift applications with the following command:
$ rhc-ctl-app -a habari07 -c add-alias --alias openshift.skippy.net -l firstname.lastname@example.org
Obviously you'll need to set up the appropriate CNAME record for the alias you define to point to your app's rhcloud.com address.
I set up another repository for Habari 0.7 using MySQL, but discovered in the process that the Habari automated installation mechanism doesn't work properly for MySQL. You can still easily deploy Habari using MySQL on OpenShift, but you'll need to take note of the database details provided to you when you run
rhc-ctl-app -a $APPNAME -e add-mysql-5.1 -l $USERNAME
When you visit your app's URL, you'll get the Habari installation screen, which will require you to plug in the database details. Not a big deal, but not quite as fun as a completely automated installation!
The upcoming release of Habari 0.8 should resolve this problem for MySQL installations, so I'll make a new OpenShift Quickstart for that once it's out.
I acquired a Pogoplug device awhile back, and on the whole I find it a neat little gadget. The user interface is okay, but not great; but really I don't need another web-based storage location. I've already got Dropbox and Ubuntu One accounts that I hardly use, so being able to store more data online -- albeit on hardware I control -- just isn't that useful. What I would like, though, is a small, low-power Linux server that I can use for a variety of useful tasks.
The Pogoplug has 256 megabytes of RAM, so anything I might do with it needs to have minimal system requirements. I decided to try to install Habari, mostly just to see if I could. Habari can use SQLite as its datastore rather than a complex relational database server, and requires only an http process that can handle PHP. This means it can use lighttpd or nginx rather than Apache. Using SQLite severely restricts the potential performance and scalability of Habari, but with only 256MB RAM I'm already severely limited in how much I might be able to scale.
It was trivially easy to install Debian on the Pogoplug device. I booted from a USB stick which contains the root filesystem. I added a 500GB external drive, and gave it three partitions: swap, /var and /home. The Debian install had basically no services running other than sshd -- no syslog, no cups, no avahi, no nothing. I installed nginx and PHP. In order to get nginx to handle the PHP processes, I needed to install the spawn-fcgi package.
Then I just followed the Habari nginx instructions, and I had a blog running! With nginx, spawn-fcgi and a screen session connected to IRC, I still have 7 megs of unused memory, and I haven't dipped into swap at all!
skippy@debian:~$ free -m total used free shared buffers cached Mem: 249 242 7 0 11 205 -/+ buffers/cache: 25 224 Swap: 2047 0 2047 skippy@debian:~$ vmstat -a procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free inact active si so bi bo in cs us sy id wa 0 0 0 7328 197228 37972 0 0 0 25 36 39 0 0 99 0
Of course this little blog isn't actually handling any traffic, but it's nice to know that I have a self-contained, self-hosted Habari environment on which I can hack.
The Habari community has been discussing for some time an event at which we can all meet one another in person, work a little bit on Habari, help new users learn about our little project, and get to know one another better in a more social context. To that end, we're planning Habari Party 2009 to take place on Saturday, September 12 in lovely Columbus, Ohio. I've secured the Downtown Technology Center as a venue for us, and I'm looking forward to meeting some good friends for the first time. We plan to have Habari-specific discussions and activities in the morning and early afternoon, followed by dinner and drinks somewhere nearby.
We'd like to make this event open to the general public, but we're not entirely sure how to do that. So I'm looking for feedback from the broader blogging community. If you're not currently using Habari for your blog, what sort of events might encourage you to attend our little party? Would you like in-depth walkthroughs of Habari features? Would you like to see Habari installed and configured, with explanations of the process along the way? Would you like the opportunity to speak directly with Habari developers about the features you desperately want from a blogging platform?
If you're a developer, would you be interested in learning how Habari works under the hood? Would you like to discuss plugins and how to write them? Would you like to engage core Habari developers about those aspects of your current solution that are overly complex, in order to influence Habari's future development in your favor?
If you're a themer, what sorts of conversations would you like to have with the Habari community?
Habari is much more than just a blogging tool. It truly is a rich community of passionate users. I've thoroughly enjoyed getting to know people in the Habari community, and I want very much to share that experience with others. Please leave a comment with suggestions for things that might entice you to attend Habari Party 2009, so that we can include you in our community!
This website is powered by Habari. Habari is powered by people just like you and me. We've been working on Habari for a little over two years now, and it's every bit as fun and satisfying as it was when we first got started. Our community has grown from just a couple friends to a worldwide group of smart, passionate users and developers.
This fall, we're planning the first in-person Habari get-together, an opportunity for people using and working on Habari to meet one another. We've always said that community is greater than code, so this little conference is a terrific opportunity to better cement friendships, and bolster our community.
The date of our little event will be September 12. This is fairly arbitrary, and was decided mostly because Michael will be in the States at that time anyway. It was generally agreed that it was extremely unlikely that many of us would be able to go to Australia any time soon, so the Habari get-together should capitalize on Micheal's existing travel plans. :)
Now the big challenge is: what the heck do we call this little shindig? It would be easy to call it something like HabariCon or BarCamp: Habari or similar. Michael's been advocating HabariBar to indicate the (intended) barcamp nature of the event, but also to play on the notion that all the real fun at such events happens at the bar afterwards, anyway! Plus, it's a unique name that isn't likely to get confused with other barcamps or unconferences.
But Owen complained recently that
As a tech people, we need to stop using "pod", "foo", "bar", and "camp" in the names of events we expect serious people (with $) to come to.
Even though we're not going to be charging admission for our event, I share Owen's opinion. The "Camp" suffix, and the Foo|Bar|Pod prefixes are tired. They don't adequately explain to the general public just what the event is, or why they should consider attending. Granted, any Habari event isn't necessarily going to be interesting to the general public, but we (or at least I) would like to have an open event such that curious folks could come learn and participate.
But the alternatives aren't much better. First Annual Habari Conference, Habari Extravaganza and the like provide as poor a description as anything else. This will be, at least for this year, a small-ish event of people who mostly know one another online, and are looking to establish real-world connections with one another.
This first Habari event will take place in Columbus, Ohio. Why? Columbus makes a reasonable middle ground for many of the folks who have expressed an interest in attending. Mostly, though, because I'm here, and I'm coordinating it! I thought a clever idea would be to name our (hopefully recurring) event after the location in which it takes place. Thus, this first Habari event could be OH Habari! If shep ever hosts an event, we can call it MO Habari! And if any Hawaiian Habari users want to organize something, we could have HI Habari!
Alas, this format falls down for international locations. If h0bbel hosts, we'd have NO Habari, which might not be the best naming choice.
What sorts of event names can you think of that might catch your interest sufficiently that you would consider spending a couple hours to learn more about Habari? What sorts of names can you think of that don't actively exclude folks, or discourage participation? We (or at least I) don't want this to be a closed party, just for long-time Habari developers.
home / contact / flickr / github / keybase / linkedin / twitter
The contents of skippy are licensed under a Creative Commons Attribution 4.0 International License.