As with Linux, Firefox and Thunderbird are available for Solaris and OpenSolaris in a variety of forms: supplied with the OS, installed separately from a pkg and installed separately from a tarball (both available from Mozilla.org). Of these, the only way you can get any sort of automatic update is with the first option: via an OS update and this tends to lag behind the available releases by quite some margin. Well, that's about to change, at least for some people.
I'll get straight into the technical details and leave the background behind all of this to the very end.
This post and the accompanying code was inspired by this article on Mozilla Developer Center.
: Ooops, it would seem the automatic update DOES work by default for the tarball downloads, it just doesn't offer an automatic upgrade between 3.5.x and 3.6.x as I was testing. I'll leave the rest of this post as is as an "education" for those wanting to implement their own internal crude update system.
Lets get this out of the way early, and put it in lights:
If you don't meet this single one requirement, then the rest of this post is purely informational to you.
The requirements are quite modest. All you need is a web server capable of running PHP (with allow_url_fopen enabled) and ideally with HTTPS/SSL support. This web server can be on an internal private network, but it needs to be able to communicate with the Mozilla.org servers.
The HTTPS/SSL requirement is not essential, but highly recommended if your web server will be accessed across a public network...
Every user will ping the update server regularly whether there's an update or not (once a day by default). Any user who connects from outside your protected network - particularly from a public WiFi hotspot - can potentially have their connection hijacked and be fed a malicious update. SSL protects against this attack. The update.xml files are small, don't sweat the SSL overhead.
The large updates themselves can be safely served from a non-secure server because the update files contain a hash that the client will verify. The hash can be trusted only if the update.xml is served securely.
— MDC - Setting up an update server
These steps assume your web server is already up and running and configured for PHP.
localhost/moz" to correctly reflect the server name and path. You'll note I've not used "SEO friendly" URLs. I've done this deliberately as it adds and entirely unnecessary configuration step.
prefs.jsand add the following line:
As above, change "
localhost/moz" to correctly reflect the server name and path.
The PHP script is really quite simple and should be easy enough to follow, modify and customise to suit your needs. It should work out the box, though you may want to make a few changes to suit your needs and provide a quicker response:
$mirrorto point to your nearest mirror. Just copy and paste the URL from the Mozilla mirrors list. Be sure to check it actually has the necessary
$thunderbirdto point to the version specific
latest-#.#directory you wish to use for your updates. By default the PHP script will use the latest, but it you want to restrict things to a particular branch or use a beta branch, you'll need to change this.
For example, if you're using Thunderbird 3.1 beta, set
$thunderbird to "
I've released this script under the Apache License, Version 2 so you're free to make changes etc within the terms of this license. I'm also providing it as-is without any support or assistance, though I may offer some assistance if needed. On a side note, I don't think it would be too hard to modify the script to provide your own internal update server or provide updates for other operating systems like Linux.
Right, now we've got all the technical stuff out of the way, if you're curious to find out how I came about writing this, read on...
Years ago I switched to almost exclusively using a Sunray for my day-to-day work, and I very quickly discovered the long lag between a new release of Firefox/Thunderbird being released and the OS being updated. It was at this time that I started running Firefox and Thunderbird from my home directory. Everytime there was a new release available, I'd check the well hidden contrib directory (
http://releases.mozilla.org/pub/mozilla.org/$APP/releases/latest/contrib/solaris_tarball/) to see if a Solaris/OpenSolaris release was available. If there was, I'd download the tarball, install it into my home directory, test it, and then remove the old version. This is a bit of a schlep and I ended up writing a shell script that did this for me.
I noticed the other day that for some reason my script hadn't updated my Firefox instance in a while so I set to investigating why, and that's when I asked myself "Why am I re-inventing the wheel? Firefox/Thunderbird already has an update facility built in, why not use that?"
So I did some investigating and discovered the basic method the Mozilla apps use to determine if an update is available and the files it uses to perform the update. I then discovered that the Mozilla community doesn't actually support the Solaris/OpenSolaris builds, so the Mozilla.org update servers (AUS) don't return anything useful for the requests the Solaris/OpenSolaris instances make, even though the Mozilla archive files (
.mar) exist. I then hypothesized that provided the applications receive an appropriate response, they'd perform the update as they do on Windows and OS X, so I created the PHP script mentioned in this post and sure enough, it worked a treat.
The script itself doesn't do very much. All it does is provide the XML response which points to the official location of the download files. This script effectively does what the Mozilla AUS servers do, but for Solaris/OpenSolaris. No other files need to be stored on your server.