So long (PHP) and thanks for all the $fish

The news is out and about, so I figure I should talk about it a little. Mozilla is no longer running PHP internally for Sync, and we won’t be doing further development on the main sync server (if some horrible security hole comes up for the minimal server, I’ll try and update it, but that too is ultimately deprecated).

The reasons for this had nothing to do with the language, and any attempt to turn it into a my-language-is-superior talking point is misguided. PHP was chosen initially because we were low on internal ops resources and it was the fastest thing I could stand up at the time, not as a way of making a language statement. It served us well for years, was reasonably easy to work with, had libraries for everything we needed and continued to perform acceptably even as we grow our userbase quite substantially. It had its quirks (encoding handling is… interesting) though I have yet to find a language that lacks them. On the whole, I’m pretty happy with the original choice and would consider using PHP again in the future.

So why switch? Ultimately, it came down to the network effect. Almost all other server initiatives at Mozilla (such as SUMO and AMO) are in python, leaving sync as a one-off. That meant we couldn’t leverage a whole lot of fantastically talented webdevs when we ran into problems or needed ideas on how to approach new requirements. Our rockstar operational team was happy to work in multiple languages with multiple deployment methods, but there was no compelling technical reason to put them through the hassle. From a dev perspective, python was just another language to learn, and we got some very talented developers on board to help those of us who needed to get up to speed (and python isn’t exactly miles from php, even if some of my early attempts now look a bit cringeworthy).

So yeah, we’re all python now. Congrats to Tarek for doing the heavy lifting to make this happen and to Pete for a last-minute deep-network-voodoo save that Tarek talks about in his blog. In our datacenters, things are humming along nicely.

We’re working to get the python server to be as easy to install as possible for everyone who wants to host their own data. We’re discovering that on most systems, it’s fantastically easy, and for the others, come ask for help on #sync (irc.mozilla.org) and we’ll try to add your system to that list!

Fixing the python config file if you’re getting server errors

Some folks may see errors when trying to use their own python sync server. This actually has nothing to do with the FF5 launch, but a change in the latest tag. We used to have a mapping set that let us map some backends to shorter names, so that we could say “backend = sql” (et al) in the config file. That wasn’t all that great for the long run, so we ditched it.

Fixing this should be simple. Edit your configs to update to the following (assuming you’re using SQL):

[storage]
backend = syncstorage.storage.sql.SQLStorage
…
[auth]
backend = services.auth.sql.SQLAuth
…

Sorry we missed that that one had gone public. We try to keep things as backwards-compatible as possible, but it doesn’t always happen.

Speaking of which, we’re doing a bunch of overhaul to the core modules. Most of it will be transparent, but there will be some changes that require some table alterations to the user table. I’ll have a post up before any of the new servers go up that use the new core infrastructure.

API Version Change Coming in Aurora

If you are moving on to the new Auroras builds of Firefox (kind of like blessed nightlies) and are running a pre-March version of the Weave Minimal Server, you may find things break. That’s because this build is trying to find API version 1.1, and the older minimal servers only recognize up to 1.0.

It’s an easy fix – either update to the current weave_minimal tarball (as discussed in the previous post) or change line 62 of php to:

if ($version != ’1.0′ && $version != ’1.1′)

And you’ll be back up and running (the api differences are largely irrelevant to the minimal server)

Updating (and Deprecating) the Weave Minimal Server

With the release of Firefox 4 (yay!), the sync experience is much more integrated into the browser. However, some of the changes are problematic for the minimal server. There are a couple you may need to know about:

1) Because Firefox looks for some user functions, the setup process to access a minimal server is non-standard. It goes like this:

1. register the account with the create_user script. This has been updated to understand email addresses as usernames and will correctly convert them to the base32-encoded equivalent. Note that this is not your sync key or anything like that. It’s just an encoding of your username.

   FF4 Sync no longer exposes the concept of a sync key, so this may be unfamilliar to people. Think of it as your ssh passphrase for Sync. It should be secure and reasonably long.

2. in Firefox preferences, under sync, click on “Set Up Firefox Sync”
3. Choose “I already have a Firefox Sync account”
4. On the next screen, ignore all the nifty JPAKE stuff and click on “I don’t have the device with me” (You can use this for adding new devices to an already-configured account)
5. The resulting screen will look like a connection screen you might expect. Make sure to select a custom server, and don’t forget the / at the end of your url if you use a prefix such as /weave/. You will need to know your secret Sync Key, but that’s no different than before.

That should be it!

2) There’s a new version of the minimal server. For many of you, this will not be a needed upgrade. However, it puts in new support for quota data, lets you use email addresses as usernames and addresses a few functions-in-parameters problems that some versions of php have. If you’re running smoothly right now, you may not want to upgrade, but if any of the above is giving you trouble, you can get it from hg ( in the weave_minimal directory) or grab the updated tarball.

This will almost certainly be the last update to the minimal server. This is not a change in philosophy – we’re still big believers that people should be able to host their own data – but a reflection of the fact that the python server is the future. There are several reasons for this:

1. The python server provides the full set of functionality, including the user api.
2. The python server is exactly the same codebase as we’re rolling out across Mozilla, which means we’ll only need to maintain one codebase moving forwards. It’s not just the minimal php server we’re deprecating. The full one will be going away as well.
3. It’s almost as easy to set up as the minimal server, but gives you lots of tasty configuration options if you want to do more advanced things

You can check out and build the full server at http://hg.mozilla.org/services/server-full/ and get lots of details on how to build it at http://docs.services.mozilla.com/howtos/run-sync.html. We’d love to hear feedback you have on it.

More alternate server possibilities

Not so much a complete system, but if you’ve been looking to get Sync working on Nginx, there’s a solution available. It’s a pretty impressive piece of work!

Weave Server on Google App Engine

Les Orchard is a true hero among men, a bearded scourge of the frozen North, and an old friend of mine.

None of this is relevant. However, the fact that he’s put together a version of the Weave Server for Google App Engine seems entirely relevant.

We believe in the power of the service, not in the intrinsic value of owning your data (heck, we can’t do anything with it, since we can’t read it!), and that’s why it’s always been important to us that users have ways to host it themselves. This is why all the code is published, why we have a minimal server and why we think that alternate easy-to-install solutions are full of awesome. Now you have another way to maintain control of your data.

Go forth to his blog and tell him he’s your hero.

HG repository change for Weave servers

As part of the promotion of Sync from experimental labs version to full-blown production, we’ve migrated them out of the labs hg repository. That means that if you try to pull from them, you’ll get an error.

The new locations are:

Sync: http://hg.mozilla.org/services/sync-server/
Registration: http://hg.mozilla.org/services/reg-server/

Minimal server is unaffected by this, so if you’re running that from the tarball, nothing to worry about.

DB Changes to Weave Server (full version)

We’re a couple weeks away (mostly load testing) from tagging an official 1.3 version of the Weave Server, but if you have a current installation of the registration API (using mysql) and pull from the hg tip, you’ll need to make a pair of database changes to get things working right:

alter table users change column md5 password_hash varbinary(128);
alter table users add column reset_expiration datetime;

This allows us to do individually seeded hashes of passwords (and there’s code in place to auto-update when someone logs in), and to expire reset codes after 6 hours so that an unused one doesn’t stick around.

There are no changes needed if you are running the minimal server.

Weave Server 1.0 official release

With the release of the 1.0 client, we also have a new release of the 1.0 server! There’s no rush to upgrade, since the prior version is API compatible, but you’ll probably want to upgrade soon to take advantage of the various fixes.

There are a bunch of structural improvements, and a few major architecture changes. The most notable one of these is that we’ve completely separated the registration piece from the sync piece. This is mostly for futureproofing – we plan to have additional services in the future, and this will alow you to pick and choose the ones you need, as well as version them separately – but also allows you to install just the sync portion and handle registration however you like.

The second major change is that we’ve discontinued support for SQLite in the main architecture. If you’re using SQLite, you’re far better off using the Weave Minimal Server (which is already compatible with 1.0 and doesn’t have an update). It’s at http://people.mozilla.org/~telliott/weave_minimal.tgz

One final tweak of note – the client for the user API uses a 1.0 version number (instead of 1) to make the two services match. Just edit the current /user/1 alias in your apache config to 1.0 and you’ll be good to go.

The new registration server is here:

http://hg.mozilla.org/labs/weaveserver-registration

(hg revision 0575a21fbca2)

The new sync server is here:

http://hg.mozilla.org/labs/weaveserver-sync

(hg revision d7e22931c0fc)

Each instance has a README file that can walk you through the install process, and we’ve done a bunch of work to clean up the constants file to make it easier to understand and install. If you’ve have a fairly recent server, you probably don’t need to mess with your database – check to see if the username column is an integer – if it is, you’re up to date.

As always, the API documentation and some setup assistance can be found at:

https://wiki.mozilla.org/Labs/Weave/API

and we have a server mailing list at

http://groups.google.com/group/mozilla-labs-weave-server-users

where you can get install help and we can try to troubleshoot problems.

Happy Syncing!

Weave Minimal Server update

I’ve updated the server so that it’ll be compliant with the upcoming 1.0 beta release. There are three ways to play along at home, in order of most difficult first:

1) grab http://people.mozilla.com/~telliott/weave_minimal.tgz and do a fresh install. Ick. That’s way too much hassle.

2) grab http://people.mozilla.com/~telliott/weave_minimal.tgz, untar it somewhere and replace the index.php file in your weave_minimal folder.

3) Go to your current install and change index.php line 119 from

if ($version != ’0.5′)

to
if ($version != ’0.5′ && $version != ’1.0′)

Yeah, it really is that straightforward. And it’s backwards compatible!

Working on documentation for the full server install. Unfortunately, that one is a lot more complicated, especially if you’re using mysql.