1. Supported platforms
The following Linux distributions are supported:
Debian 6 (Squeeze), 7 (Wheezy), and 8 (Jessie)
Fedora 17, 18
Ubuntu 12.04 LTS (Precise Pangolin) and 14.04 (Trusty Tahr)
2. OpenSRF 2.4.2
OpenSRF 2.4.2 is a security release. Users of 2.4.1 and earlier are strongly urged to upgrade as soon as possible.
2.1. Bugfixes in 2.4.2
LP#1652382: improve normalization of memcache keys to avoid potential denial of service and privilege escalation attacks.
LP#1652122: fix an infinite recursion bug in opensrf.system.method.all.
LP#1655449: propagate bundling/chunking limits to subrequests.
LP#1559121: remove support for Debian Squeeze
LP#1350457: pass caller’s session to subrequests called via method_lookup
LP#1494486: limit damage caused by dropped drone XMPP socket
LP#1474507: fix interval_to_seconds for weeks and seconds
We would like to acknowledge the following people who contributed to OpenSRF 2.4.2:
3. OpenSRF 2.4.1
3.1. Enhancements in 2.4.1
3.1.1. Improved documentation for configuring ejabberd on Debian Jessie (LP#1445503)
The documentation now reflects the fact that the version of ejabberd packaged for Jessie uses a new configuration file format.
3.1.2. Minor srfsh enhancements (LP#1436047, LP#1152272)
srfsh now accepts a new command-line switch, --safe. When --safe is supplied, srfsh will not allow the user to use the bang (!) command to run an external program.
Also, when srfsh is run non-interactively (e.g., srfsh /path/to/script.srfsh or srfsh < /path/to/script.srfsh), it no longer records the commands run in the srfsh history file (~/.srfsh_history). This allows srfsh to be invoked as a cronjob without cluttering up its command history.
3.2. Bugfixes in 2.4.0
3.2.1. Avoid re-sending messages extraneously over WebSockets (LP#1418613)
Testers of the prototype Evergreen web staff client are particularly encouraged to upgrade OpenSRF to get this bugfix.
3.2.2. srfsh no longer closes STDOUT prematurely (LP#1461625)
When run non-interactively, srfsh used to close STDOUT after handling the first command, which meant that the output of subsequent commands was not displayed. This is now fixed.
3.2.3. Python gateway client now supports HTTPS-only gateways (LP#1409055)
The Python gateway client used to coerce gateway requests to HTTP. As of this release, if the value supplied to setDefaultHost() starts with "https://" or "http://", the specified protocol is used.
4. OpenSRF 2.4.0
4.1. New features in 2.4.0
4.1.1. WebSockets support (LP#1268619)
WebSockets are a standards-compliant, cross-browser mechanism to support streaming, bi-directional communication between the browser and the server. For more information, see http://en.wikipedia.org/wiki/WebSocket
To install the WebSockets gateway, follow the instructions in README.websockets. By default, the WebSockets gateway listens on ports 7680 and 7682 and uses a separate Apache instance.
4.1.2. Cross Origin Resource Sharing for OpenSRF (LP#1002028)
Browsers' same-origin policy currently restricts requests to the current website’s domain to prevent various nefarious scenarios. However, because APIs and other web resources need to remain open to cross-site use, Cross Origin Resource Sharing (CORS) was created to allow services to formally authorize cross-origin requests. CORS makes it simple to use OpenSRF’s HTTP translator and gateway APIs on websites using separate domains.
A couple examples of scenarios where this would be useful:
A library would like an AJAX-driven "quicksearch" box on their main site, which is hosted on a different domain than their catalog.
A developer wants to create new web applications and services that tie into Evergreen, but does not wish to install Evergreen locally or configure a proxy.
Domains that are allowed to send cross-origin requests can now be specified in opensrf_core.xml as cross_origin/origin elements in the gateway element (full XPath /config/gateway/cross_origin/origin).
4.1.3. Support for log tagging (LP#1343578)
It is now possible to specify a log tag, i.e., a string to append to the application name in syslog message. This allows easy filtering of log entries when running multiple OpenSRF instances on the same server.
Log tags can be set by adding logtag elements in opensrf_core.xml.
4.2. Enhancements in 2.4.0
The routines JSON2js and js2JSON now use native browser JSON routines. In addition, jsonPretty is removed in favor of JSON.stringify.
4.2.2. Listeners now log and drop XMPP error messages (LP#1341687)
The most common form of XMPP error messages are "bounced" messages, i.e. those where the recipient is not available. Instead of passing these useless and confusing messages down to a drone for processing, listeners now log the error and drop the message.
An example of when this can occur is when a service is starting up and attempts to register with a router that is not yet available.
4.2.3. Removes osrf_ctl.sh (LP#1286248)
The control script osrf_ctl.sh is removed in favor of osrf_control, which was introduced in OpenSRF 2.3.0.
4.2.4. Improved docgen output(LP#1292214)
Docgen output now respects formatting present in method description.
4.2.5. Other enhancements
Add support for Debian Jessie (LP#1306044)
Add support for Ubuntu Trusty (and removes support for Lucid) (LP#1315525)
Remove deprecated Jabber registration script (LP#1306044)
Improve const-correctness of osrfCachePutString and osrfCachePutObject (LP#1234816)
Document that perl2JSON doesn’t order hash keys (LP#1285915)
Reorder changes to ejabberd.cfg in the install instructions
4.3. Bugfixes in 2.4.0
4.3.1. OpenSRF.pm no longer supplies AUTOLOAD (LP#1179660)
Instead of simply producing an error message in the OpenSRF logs, calls to nonexistent subroutines are now fatal errors which will stop code execution.
4.3.2. osrf_control only affects processes owned by current user (LP#1337401)
As of 2.3.0, OpenSRF can readily support running multiple instances on one server. This bugfix ensures that osrf_control only affects OpenSRF processes owened by the current user.