Posts tagged with “”

Share an Apache Config With Dropbox

Like many, I run local development environments. I have no love for a shared development environment. Also like many, I split time between two computers—one at home and another at the office. Finally, still clutching the “like many” mantra, my work-life balance kind of sucks. My vocation is also my avocation, so when I’m working on something interesting, it follows me around from location to location, computer to computer with no regard for this mythical concept of balance.

I’ve always had different systems for work and play and it’s no secret that I’m a huge fan of Dropbox, so sharing what I need to and can has always been part of my setup. In the past, though, my systems have always been heterogeneous; a Mac at home, Windows or Linux at the office. Because the environments were different enough, sharing was often a rudimentary effort that involved multiple variations of a file that was optimized for its runtime. Still useful for access and versioning, but there’s no meaningful sharing going on there.

These days both of my machines are Macs these days (yay!) and both run Apache installed via MacPorts, so a few months back I decided it was time to share properly. My httpd.conf file was already in my Dropbox, as were a few projects that I like to have access to on either machine so I expected this to be easy. And it was.

Except that it wasn’t. The sand in the gears is that my username on each machine is different. That makes my home directory different on each machine and Macs, more so that either Windows or Linux, really encourage users to keep everything in their home directories. To some degree, that last statement is my own projection—I realize that it’s possible and even easy to install and store files anywhere—but I’ve really liked keeping everything in that tight of a grouping and wanted to continue doing so. That left me with the problem that I couldn’t hard code my paths.

Before we go on, I should outline my configuration at a very high level. I do everything web-related in virtual hosts. The reasons for doing so are beyond the scope of this post, but suffice to say that it’s something I think every developer should be doing. The fact that I still see developers working in circa-1998 directories beneath a single web root makes me crazy.

Anyway, back to the sharing. My Dropbox is in the standard location at ∼/Dropbox and my development environments are all in ∼/Development/domains. Similarly, for convenience, I keep my virtual host configs in individual files that I can easily include or uninclude. Those that I want to be able to access on either machine are stored in my Dropbox (∼/Dropbox/Application Support/apache/conf.d) and those that I don’t are stored in my Application Support directory (∼/Library/Application Support/MacPorts/apache/conf.d).

That’s a lot of resources tucked neatly into a directory that’s different on each machine that I want to share across, but fortunately Apache understands environment variables, so I just tweaked my httpd.conf and shared virtual host config files. I replaced each path that explicitly referenced my home directory with ${HOME}. For example:

Include "${HOME}/Dropbox/Application Support/apache/conf.d/*.conf"
Include "${HOME}/Library/Application Support/MacPorts/apache/conf.d/*.conf"

Once complete, I bounced Apache and everything worked.

Except that it didn’t. You didn’t really think it’d be that easy, did you?

Some time later, after a reboot, I noticed that Apache didn’t start automatically like it always had in the past. I don’t reboot often, so my Apache config changes were ancient history; I just chalked it up to a hiccup, started Apache manually and went on with my day. Eventually, in spite of the infrequency of reboots, I came to recognize a pattern. Something was wrong.

This post has become longer than I intended, so I’ll cut to the chase. The problem is that, at boot, Apache isn’t starting as me, so it doesn’t understand the ${HOME} directory I told it to use. Once booted, that’s not a problem, so manual starts worked just fine. I tried several solutions and asked questions related to this on StackOverflow here, here and here (in the order of their asking). Eventually I had to settle for a Linux-like file system config coupled with symlink usage to maintain my OS X consolidation.

I already had my Apache config file (/opt/local/apache2/conf/httpd.confJ) symlinked to a physical file in my Dropbox, so that was fine. Next I needed to access my shared and local virtual host config files, so I created /opt/local/apache2/conf.d. Inside of that directory, I created two symlinks. local pointed to my non-shared virtual host files in ∼/Library/Application Support/MacPorts/apache/conf.d and shared pointed to the shared config files in ∼/Dropbox/Application Support/apache/conf.d.

Next I needed to be able to access my development environments from outside of my home directory. I chose the Linux-like path of /var/www. I created a symlink such that /var/www pointed to ∼/Development/domains.

Finally, I just updated my Apache config so that it loaded the virtual host config files using a relative path:

Include "conf.d/*.conf"
Include "conf.d/*.conf"

And updated all of my virtual host configurations so that all resources were being accessed through /var/www instead of my home directory.

Dropbox is Smart

Rands in Repose on just what makes Dropbox so special:

The magic of Dropbox is that it doesn’t ask you to think about what you do. You care about one thing: do I have access to the most recent version of my files? And with Dropbox, yes, you do. Wherever you are, so are your files.

I’ve been espousing Dropbox for a while now, but this is a well-articulated macro view.

Remove Conflicted Files from Dropbox

Because I use Dropbox to share selected runtime data (read: Firefox profile information) across machines and because I occasionally forget to exit the runtime environment (read: Firefox) when I move between those machines, Dropbox creates conflicted files from time to time. The conflicted files are saved separately and are named something like this:

places (my.machine.name's conflicted copy 2008-11-13).sqlite

The file above is my Firefox bookmarks database. I have no idea how it came to be in a conflicted state, but the ugly truth is that I don’t care. I assume that Dropbox saves these files as a safety measure against losing their customers’ data and so that the customer can perform a diff on those files if they choose. I don’t choose. I keep convenience files in my Dropbox, not critical files, so the files themselves are not worth the effort it would take to find and evaluate the delta between the “good” file and the conflicted file.

To that end, I’ve taken to simply removing them and because I don’t want to browse the directory structure or do this in any other manual way, I let my operating systems do the work for me. This is easy in Unix and, since two of my machines (my two primary machines) are Unix-based (OS X and Linux), it’s easy for me:

$ cd ~/Dropbox
$ find . -type f -name "* conflicted *" -exec rm -f {} \;

Poof. Now they’re deleted and Dropbox will delete them from my Windows boxes for me. I’m sure that there’s a way to do something similar on Windows, but my DOS skills atrophied many moons ago.

Dropbox, Firefox, Synchronization and Gnome Do

I’ve written about Dropbox, I’ve written about Firefox, I’ve written about synchronizing Firefox through Dropbox. In fact, I’ve written about using Dropbox to sync Firefox twice. I’ve also written about using Gnome Do to launch bookmarks (albeit as an update to a post about using Launchy to do so).

Shortly fter applying a more targeted technique for synchronizing Firefox through Dropbox, I realized that Gnome Do had stopped indexing bookmarks on my Linux machine. After looking around and asking a few questions, I realized that Do had been updated so that it no longer indexed bookmarks.html, but rather included a JSON parser that parsed the Firefox backup files that are created automatically. That required one additional change:

$ cd ~/Dropbox/Application Support/firefox/profile-share
$ cp -r ~/Dropbox/Application Support/firefox/profiles/wg3x0vhj.dropbox/bookmarkbackups/ .
$ cd ~/.mozilla/firefox/erbbyfam.default
$ mv bookmarkbackups bookmarkbackups.orig
$ ln -s ~/Dropbox/Application Support/firefox/profile-share/bookmarkbackups bookmarkbackups

After restarting Do, I was able to launch my Firefox bookmarks without a single click.

Redux: Synchronizing Firefox Through Dropbox

For the most part, the Dropbox-enabled synchronization of Firefox that I wrote about a couple of months ago has been reasonably solid. A few hiccups and a few annoyances, but nothing serious or even significant enough to warrant a change of approach. This morning, though, that changed and I needed to re-evaluate my synchronization strategy.

Yesterday.

Until today, I’ve been running something of a kitchen sink mechanism. You can read the full post for the details, but I was sharing my entire Firefox profile across multiple systems and platforms using Dropbox activity. Bookmarks, extensions, cookies, history and everything else. The transparent and immediate way that Dropbox works made this possible.

Over the last couple of months of using this method across one Mac client, one Linux client and two lesser used Windows clients, I’ve been bothered by several side effects:

  • Sharing profiles is chatty. Really chatty. I noticed this immediately and even mentioned it in my original post, but damn. Sharing an entire profile means a lot of Dropbox activity. Turning off system tray notifications in the preferences helped, but I kid you not when I tell you that the little blue animated icon overlay never stopped spinning. Unless Firefox wasn’t running at all, that thing was spinning like a madman.
  • When I move from machine to machine, I’m not as diligent as I should be about quitting Firefox on the machine I’m leaving. Because of this, I assume, I ended up with a lot conflicted files in my Dropbox-mounted, shared profile directory after a while. This isn’t really a problem, as far as I know, but I hate clutter.
  • Virtually every time I launched Firefox, I got the prompt that tells me my last session quit unexpectedly and asks whether I want to start a new session or restore my last. Because of the difference between how Mac and Windows/Linux order OK/Cancel buttons (even when the buttons don’t actually say OK or Cancel), I’d often find myself hitting the wrong one. Remember, I work in all platforms.

All of these actions by both applications, of course, are absolutely correct. Both Dropbox and Firefox were behaving exactly as expected, but the necessary side effects of the architecture I had concocted were still annoying.

Today.

This morning things got a bit more dire. Firefox simply wouldn’t launch while I was at work on my Linux machine. No matter how I tried – command line, Applications menu, Gnome Do, etc. – Firefox just wouldn’t start. There was no error or indication of an issue, Firefox just, well, did nothing at all. When I launched Firefox into the Profile Manager, though, I was able to select the default profile rather than my Dropbox-ified profile and run Firefox happily.

Knowing that the problem was in my shared profile created a level of severity that I needed to address.

Fixed.

Now that simple annoyance had turned to need, I set about defining a less brutish synchronization mechanism. What I really want synchronized across all of my machines – the profile elements that are most needed and yet the biggest pain to synchronize manually – are my bookmarks, my extensions and my Greasemonkey scripts so I decided to apply a more targeted solution.

Leaving my shared profile directory in place, I created a new Dropbox directory outside of my shared profile directory. To this directory, I copied what I wanted to synchronize from my Dropbox-shared profile. Then, in my default profile – the profile that is local to each machine rather than shared en masse via Dropbox – I created symbolic links to the bits I just copied.

Here’s what it looks like from the shell:


$ mkdir ~/Dropbox/Application Support/firefox/profile-share
$ cd ~/Dropbox/Application Support/firefox/profile-share
$ cp ~/Dropbox/Application Support/firefox/profiles/wg3x0vhj.dropbox/bookmarks.html .
$ cp ~/Dropbox/Application Support/firefox/profiles/wg3x0vhj.dropbox/places.sqlite .
$ cp -r ~/Dropbox/Application Support/firefox/profiles/wg3x0vhj.dropbox/extensions/ .
$ cp -r ~/Dropbox/Application Support/firefox/profiles/wg3x0vhj.dropbox/gm_scripts/ .
$ cd ~/.mozilla/firefox/erbbyfam.default
$ mv bookmarks.html bookmarks.html.orig
$ ln -s ~/Dropbox/Application Support/firefox/profile-share/bookmarks.html bookmarks.html
$ mv places.sqlite places.sqlite.orig
$ ln -s ~/Dropbox/Application Support/firefox/profile-share/places.sqlite places.sqlite
$ mv extensions extensions.orig
$ ln -s ~/Dropbox/Application Support/firefox/profile-share/extensions extensions
$ mv gm_scripts gm_scripts.orig
$ ln -s ~/Dropbox/Application Support/firefox/profile-share/gm_scripts gm_scripts

Details.

Although I thought I knew which files and directories I needed to create my targeted solution, I spent a little time verifying just to be sure. Here are the guts of what I wanted synchronized:

  • In Firefox 3, bookmarks are stored in profile root>/places.sqlite.
  • My application launchers (Quicksilver, Gnome Do & Launchy) key off of profile root>/bookmarks.html, so I needed to synchronize that, too.
  • Extensions are stored in profile root>/extensions/.
  • Greasemonkey scripts are stored in profile root>/gm_scripts/.

The nitty-gritty is pretty readable in the shell syntax above, but here’s the high level:

  1. I created a new directory so I could keep my targeted synchronizations independent of my complete profile synchronization.
  2. From my shared profile, I copied each resource into my new directory.
  3. In my local, default Firefox profile, I renamed its copy of each resource by appending .orig.
  4. In that same local profile, I created a symbolic link for each resource to the shared version in my new directory.
  5. I restarted Firefox and my default profile looked like my old profile in all of the ways that matter to me.

Now.

Hopefully this targeted solution will be much less flaky. Of course, my browsing history, form input history, cookies, etc. won’t be synchronized, but I think I can live without that just fine. The critical path for me, I’m pretty sure, is in the things I use and update frequently: bookmarks, Greasemonkey scripts and extensions.

Epilogue

Once I got home, I logged in and gave Dropbox time to sync up with the Mac. Once sync’d, I edited the Mac’s Firefox default profile and created the same symbolic links I’d created on my Linux machine. After restarting, the default profile loaded up beautifully here too.

I’ll keep an eye over the next few weeks, but hopefully this will be every bit as effective as my kitchen sink solution, but without the annoyances.

← Earlier Posts Page 1 of 2