Multiplexing the SOAP requests in the web administration is important, because typical installations have anything between 2 and 20 email gateway nodes. Some time ago we blogged about how the made the SOAP client in the end-user interface asynchronous. However, in the email gateway’s admin interface the multiplexing has been supported by the rpcmplexd (that you might have noticed in the top display) since many years, because we couldn’t use the end-user interface’s curl_multi_*-based code since it doesn’t support verifying TLS certificates based on fingerprints. This wasn’t an issue for the end-user interface, because administrators could simply import a certificate on the server. In the email gateway however, it was a showstopper since the configuration’s remote_system__* (clustering) only contains the fingerprint; not the full certificate.
Philosophically, there’s one compelling reason to get rid of rpcmplexd; its the last thing that ties the admin interface to the email gateway. Our security model in which the backend‘s SOAP API is the only way to interact with the system has enabled us to run the admin interface in a sandbox for a long time. Theoretically, one could copy the entire /var/www/htdocs directory and put it on another web server, just pointing the SOAP client at a mail gateway node instead of localhost. If it wasn’t for rpcmplexd…
Well, no more! We’ve replaced it with a future-based class which extends SoapClient. It’s a stream_socket_client-based HTTP client that supports chunks and TLS using stream_socket_enable_crypto (with fingerprint verification; that’s where it all started, remember?), which is made asynchronous (using STREAM_CLIENT_ASYNC_CONNECT, stream_set_blocking and stream_select). It’s used like a typical futures-API
$future1 = $client1->future()->getVersion();
$future2 = $client2->future()->getVersion();
try {
$result1 = $future1->get()->result;
$result2 = $future2->get()->result;
} catch (SoapFault $f) {
echo $f->faultstring;
}
and will be part of the next release. While we don’t expect any administrators to actually move the admin interface of the cluster nodes, we still wanted to share with you some of the under-the-hood changes we’re doing. The next release will also add a SetTLS function to the pre-delivery script (yet another way of handling mail servers with broken SSL implementations) and a pie chart function called q() that can be used to visualize the queue and quarantine. We’re testing the upcoming release both as a minor update to 3.3 (based on FreeBSD 10.1) and as a major (binary-diff wise) update based on FreeBSD 10.2.