Calling sync version of xmpp_stream_in/out:stop could lead to messages
never being processed by c2s process if they were queued in p1_server.
This could be reproduced by when having messages in offline storage,
starting sessions, enabling stream_mgmt, sending initial presence, and then immediately
</stream:stream>, messages that mod_offline would send process would not
be bounced back by stream_mgmt.
This option was introduced to fulfill requirement of RFC3920 10.3,
but in practice it was very inconvenient and many admins were
forced to change its value to 's2s' (i.e. to behaviour that
violates the RFC). Also, it seems like in RFC6120 this requirement
no longer presents.
Those admins who used this option to block s2s with their subdomains
can use 's2s_access' option for the same purpose.
By calling erlang:get_stacktrace() inside a lager function
we obtain actually a stacktrace of the lager function, not
the one we got during exception. This is not a problem for
newest Erlang versions though.
Now every such string MUST be encapsulated into ?T() macro.
The macro itself is defined in include/translate.hrl.
Example:
-module(foo).
-export([bar/1]).
-include("translate.hrl").
bar(Lang) ->
translate:translate(Lang, ?T("baz")).
Since we now require R19, we shouldn't need that anymore.
There are still couple places where p1_time_compat:unique_timestamp() is
used as there is no direct equivalent.
The header consisted of too many unrelated stuff and macros misuse.
Some stuff is moved into scram.hrl and type_compat.hrl.
All macros have been replaced with the corresponding function calls.
TODO: probably type_compat.hrl is not even needed anymore since
we support only Erlang >= OTP 17.5
The option is supposed to be used as a fallback for certificates
validation. For instance, the option will be used if 's2s_cafile'
option is not set. The value should be a path to a file containing
CA certificate(s) in PEM format, e.g.:
ca_file: "/etc/ssl/certs/ca-bundle.pem"
The option is supposed to replace existing options 'c2s_certfile',
's2s_certfile' and 'domain_certfile'. The option accepts a list
of file paths (optionally with wildcards "*") containing either
PEM certificates or PEM private keys. At startup, ejabberd sorts
the certificates, finds matching private keys and rebuilds full
certificates chains which can be used by fast_tls. Example:
certfiles:
- "/etc/letsencrypt/live/example.org/*.pem"
- "/etc/letsencrypt/live/example.com/*.pem"
