The following Linux distributions are supported:
Debian 7 (Wheezy) and 8 (Jessie)
Fedora 17, 18
Ubuntu 14.04 (Trusty Tahr) and 16.04 LTS (Xenial Xerus)
Changes in 2.5.0-rc
The OpenSRF 2.5 release candidate includes the following addition since 2.5.0-beta:
LP#1667091: the default configuration files shipped with OpenSRF no longer include support for insecure WebSockets.
Changes in 2.5.0-beta
OpenSRF 2.5.0-beta includes the following additions since 2.5.0-alpha2:
LP#1666706: a new configure option, --with-websockets-port, to allow installers to specify the WebSockets port that clients should use.
LP#1616501: add a way for mod_perl handlers that are OpenSRF clients to detect when the web browser has disconnected, and in turn stop listening for results from XMPP requests pending when the browser disconnect happened.
Changes in 2.5.0-alpha2
OpenSRF 2.5.0-alpha2 is a security release; testers of OpenSRF 2.5.x are strongly urged to upgrade as soon as possible.
The second alpha release of OpenSRF 2.5 includes the following changes:
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.
New features in 2.5.0-alpha
Chunking and bundling (LP#1612771)
Message Bundling and Chunking
OpenSRF now supports message chunking, i.e., breaking up large OpenSRF messages across multiple XMPP envelopes. This is implemented with a new OpenSRF message type.
What was previously called chunking is now referred to as bundling: packing multiple OpenSRF messages together in a single XMPP envelope, as long as we believe more messages will be sent in the future and we are below some threshold of combined message size. The default for that threshold is 25Kb.
With this change, it is no longer necessary to change the max_stanza_size setting for ejabberd when installing OpenSRF.
Pass client timezone to server (LP#1485371)
OpenSRF has long inspected the envelope of incoming requests for information about the client’s locale and made this information available to business logic. This is used, among other things, to drive transparent translation of in-database strings within Evergreen. In addition to locale, OpenSRF will now respect client-supplied adjustment to the effective time zone in which it operates, and provide that information to the business logic layer of applications built on the framework.
For non-browser clients, such as support scripts written in Perl or other scripting languages, the local system’s mechanisms for detecting time zone is relied upon. For instance, Perl scripts can directly read the TZ environment variable.
Additionally, the srfsh client now reads its local time zone from the environment and passes that to the server.
Within OpenSRF services implemented in Perl, this information is now passed up to the business logic layer via the TZ environment variable, and is reverted to the server’s value at the end of each request. This allows automatic, transparent use of the client’s time zone in almost all cases, and provides a system-normal access mechanism when direct access is required.
For OpenSRF services implemented in C, the time zone information is provided as part of the request context object that is passed to implementation functions. In particular, this allows services that interact with a database to set the time zone in which the database interprets timestamps to that of the client.
Dispatch mode for method_lookup subrequests (LP#1631522)
There is a pattern in the wild of using OpenSRF’s method_lookup() facility to decide between one of several local methods when delegating to pre-existing logic. Often times, we want to simply hand control over to another method, but the output of a subrequest’s run() is an array of results. The caller has to know if, and how, to restructure the result for the client.
Instead, we can now call dispatch() instead of run() and have OpenSRF session control completely passed to the delegate code. This way, the delegate code need not know anything about its caller, and vice versa.
Example proxy server configurations (LP#1638651 and LP#1648188)
OpenSRF 2.5 comes with example configurations for using HAProxy or NGINX as a reverse proxy for HTTP, HTTPS, and WebSockets traffic. This can be useful for Evergreen systems that wish to use port 443 for both HTTPS and secure WebSockets traffic.
Allow admin to specify where perl modules will be installed (LP#1631520)
Add --with-perlbase option to the configure to specify an alternative location for installing the Perl modules. This can be useful for setups that want to run the Perl modules from a shared filesystem or environments that need to run multiple versions of OpenSRF simultaneously.
Users of --with-perlbase are responsible for ensuring that PERL5LIB is set appropriately.
Drop support for Debian Squeeze (LP#1559121)
Drop support for Ubuntu Precise (LP#1603708)
Add support for Ubuntu Xenial (LP#1551090)
Fix a bug with syslog configuration (LP#1473479)
Fix OpenSRF debian_sys_config order for Debian (LP#1585041)
Improvements to the installation documentation (LP#1382038)
We would like to thank the following people who contributed to OpenSRF 2.5: