Thursday, August 21, 2008

Self Hosted: Foxmarks Bookmarks Server (WebDAV)

A while ago I stumbled upon Google Browser Sync and got instantly hooked - I don't mind selling my soul to Google, it's a small price to pay for the comfort of having all my bookmarks, passwords and browsing history get automatically synchronized between all the computers I happen to use.

Privacy is for the weak.

And then something terrible happened: the service was discontinued. Did I learn my lesson? heck no. It had already become part of my routine, to bookmark some website at work, so as to check it out in detail later, at home (and vice versa).

Like, I imagine, many other disenchanted GBS users, I started looking into other synchronization solutions. The only other service that is meant to provide the same, and more, features is Mozilla Weave. But it's still in early beta, and as I write this they don't accept new users into their system. Which leaves us sync-hungry dolts with bookmarks-only synchronization services.

I've picked Foxmarks, because they sync the built-in browser bookmarks, and not some separate online list of links. Plus, the bookmarks can be stored on my own (WebDAV) server!

The Foxmarks support wiki points to an article that explains how to setup WebDAV on Apache2. I basically followed their instructions, but that HOWTO is a bit outdated - it took some futzing around before I got it right. I recommend reading the mod_dav section in the Apache2 Manual, and a more recent HOWTO at

So here's how I did it:

  1. enable modules:
    a2enmod dav_fs 
    a2enmod auth_digest
  2. create the directory for bookmarks storage:
    mkdir -p /var/www/foxmarks/.webdav

  3. generate passowrd (zungbang is the username - use your own!):
    htdigest -c /var/www/foxmarks/.webdav/.digest-password foxmarks-webdav zungbang

  4. make sure all files are owned by the www-data user:
    chown -R www-data:www-data /var/www/foxmarks

  5. create /etc/apache2/sites-available/foxmarks:
    <VirtualHost *:80>
    ServerName # fake! fake! fake!
    DocumentRoot /var/www/foxmarks
    <Directory />
    Options FollowSymLinks
    AllowOverride None
    order allow,deny
    Allow from all
    Alias /webdav /var/www/foxmarks/.webdav
    <Location /webdav>
    DAV On
    AuthType Digest
    AuthName "foxmarks-webdav"
    AuthDigestProvider file
    AuthUserFile /var/www/foxmarks/.webdav/.digest-password
    Require valid-user
    ErrorLog /var/log/apache2/error.log
    LogLevel warn
    CustomLog /var/log/apache2/access.log vhost_combined

  6. enable the new site and restart the webserver:
    a2ensite foxmarks
    /etc/init.d/apache2 restart

  7. test the setup with cadaver
    aptitude install cadaver
    you should be prompted for a username and password and succefully log in - use help to list available commands.

  8. install the Foxmarks add-on, and configure it to access your own server at:

It took several browser restarts before the Foxmarks browser add-on agreed to connect to my server for the first time (this happened on three different machines). Other than this initial mess, Foxmarks now works like a charm, correctly synchronizing my bookmarks. By the time I had this working though, an enterprising fellow found a way to hack Mozilla Weave into using a private server for storage. It too uses WebDAV, so most of the stuff above still applies. I guess I'll switch to Mozilla Weave eventually, but it'll take a while.

 [01 Sep 2008] UPDATE: "works like a charm" was a bit of an exaggeration... a few minutes ago I found out that the bookmarks store file foxmarks.json simply disappeared - I don't know how or why, but it was definitely gone. It wasn't a big deal though - I just restored the file from the nightly backup. I could've probably also attempted to "force overwrite of server bookmarks" by hitting the Upload button at the advanced tab in the Foxmarks settings dialog box, but I didn't.

 [13 Sep 2008] UPDATE #2: It happened again. Well, not quite - this time the file foxmarks.json was still there, yet it was truncated at about half its size, and the Foxmarks add-on refused to synchronize (I got a tiny red question mark right next to the Foxmarks icon in the status bar). I tried the Upload button and it worked. I'm not amused.

 [16 Oct 2008] UPDATE #3: as of version 2.5.0 Foxmarks provides password synchonization - I've been using it for the past three days and it seems to be working nicely. I'm not sure about using Mozilla Weave anymore, but who knows...

 [17 Apr 2009] UPDATE #4: I've recently updated Foxmarks to Xmarks version 3.0.2. The option to use my own server was automatically disabled, so I had to re-enable it. But for some reason I couldn't get it to sync - I only got an unspecified error in the log. I was finally able to get it working by forcing Xmarks to download the bookmarks and passwords from the server (press the Download button in the Manual Overwrite section of the Advanced tab in the Xmarks settings dialog box).

I also disabled all the options under the Discovery tab - I don't need it, and I guess it requires an Xmarks account anyway.

Mozilla Weave Beta is now open again to new users but it requires Firefox v3.5, and I'm using Iceweasel 3.0.2 (Debian/Squeeze), so it's not an option yet.

Monday, August 18, 2008

gnome-screensaver Doesn't Lock the Screen

I've configured the GNOME screen saver to lock the screen on my live-HDD after some period of no activity - it seems to make sense on a mobile platform, to prevent a passerby from messing about with my system. All was well until a recent upgrade (I can almost hear you: "when will this guy get the point?").

The screen saver comes up after a while, but it doesn't lock the screen. The password dialog box doesn't come up when I touch the mouse or keyboard, and I simply get my desktop.

My first guess: I turned off locking by mistake. Easy to check (just launch gnome-screensaver-preferences). Nope. The screen saver is definitely set to lock the screen.

My next guess: it's a bug. After a quick look at the gnome-screensaver bug page on the Debian BTS, I found bug #481119. While the reported problem isn't quite similar to my own, the bug submitter provided a workaround that seemed worth a try.

I opened up gconf-editor, found the key /apps/gnome-screensaver/lock_dialog_theme and modified its value from default to an empty string. A longshot. I know. But it works. I would never have guessed.

I'll go wait for the screen to lock now. Bye.

[Aug. 19 2008] UPDATE: I posted too early. It sometimes works and sometimes doesn't, and I can't quite put my finger on it. In the meanwhile I've reverted the value of /apps/gnome-screensaver/lock_dialog_theme to its previous default value default.

Thursday, August 14, 2008

Self Hosted: Getting Started

This is the first post in a series of posts I'm planning about self hosting: the act of hosting your own web server.

Self hosting requires a computer and an Internet connection that's on most of the time, some software (webserver and probably a database and other stuff), an account with one of the dynamic address service providers (such as No-IP and DynDNS), and last but not least: lots of free time.

In each of the following posts in this series, I'll present a specific type of website: a plain static website, Foxmarks bookmarks server (WebDAV), Gallery2 (multi-site), WordPress, Gitweb, and a CUPS proxy site.

I'm no webmaster - my experience in web hosting is limited to what I've done in the past year and half, which isn't much. Nevertheless, it's work that begs to be documented. Please don't be shy: corrections and suggestions are welcome!

I'll start with a plain static website, so as to demonstrate the steps needed to install it. I'm using Apache2 as my webserver - the default on a Debian system (if it's not installed, just type aptitude install apache2 as root).
  1. create a directory (or a symlink to a directory): /var/www/plain
  2. create a file /var/www/plain/index.html:
    <html><body>Hello World!</body></html>
  3. create a new configuration file /etc/apache2/sites-available/plain with the following contents:
    <VirtualHost *:80>
    DocumentRoot /var/www/plain
    <Directory />
    Options FollowSymLinks
    AllowOverride None
    ErrorLog /var/log/apache2/error.log
    LogLevel warn
    CustomLog /var/log/apache2/access.log vhost_combined
    (I've marked in red a fictitious No-IP domain and webmaster e-mail address - please replace with your own stuff).

  4. enable the new website:
    a2ensite plain
  5. reload the webserver:
    /etc/init.d/apache2 reload
A few notes are in order:
  1. the new site should be accessible at (fake! fake! fake!)
  2. the new site can be disabled with the following sequence:
    a2dissite plain
    /etc/init.d/apache2 reload
  3. Virtual Hosts: other similar sites with different server names can be similarly installed by modifying the ServerName property. The webserver will serve web pages according to the server name used in the URL being accessed - all from the same IP address.

  4. if you're getting the following message every time the server is reloaded or restarted:
    Could not reliably determine the server's fully qualified domain name, using for ServerName
    just add the following line to /etc/apache2/httpd.conf
  5. SECURITY: better safe than sorry...

It's your serve(r) now.

Thursday, August 7, 2008

Thinking Outside the (Virtual) Box (3)

It was quite inevitable.

Following my previous escapades with WinXP and VirtualBox, I simply had to get my live-HDD running under VirtualBox...

The first step was to create a disk image that actually points to the raw disk (see section 9.9 in the VirtualBox User Manual):
VBoxManage internalcommands createrawvmdk -filename live-hdd.vmdk -rawdisk /dev/sda -register
The next step was to create a virtual PC in VirtualBox that's based on this image. And that was basically it. There's really nothing more to it.

Well, I've also installed the VirtualBox Guest Additions on the live HDD, and that wasn't as neat.

The X server on my live HDD is configured to auto-detect the video adapter, and it works just fine, allowing easy resizing of the virtual PC display. The mouse, however, is not auto-detected. I've added the following bit of shell-script at the end of do_start in /etc/init.d/, to fix this (note the use of lspci to figure out if this is a real or virtual session):
# Setup display
rm -f /etc/X11/xorg.conf.200*
# are we running inside VirtualBox ?
if [ -z "$(lspci -d 80ee:beef)" ]; then
# real
dpkg-reconfigure -fnoninteractive xserver-xorg
# virtual
The other issue is accessing the VirtualBox shared folder. It's done like this (as root):
modprobe vboxvfs
mount -t vboxsf -o uid=zungbang,gid=zungbang,rw /vboxsvr/tmp /mnt/vbox
(replace the colored parts with the your own stuff).

It seems that mount.vboxsf doesn't grok the noauto flag, so there's no way to add entries for shared folders in /etc/fstab, if, like me, you need these to not be mounted at startup.

I'm virtually happy now.