The current comparison can only work on debian stretch, that ships php
7.0, but debian buster has a more recent version and bullseye will have
an even more recent version.
This change was suggested by @ulvida (Daniel Viñar Ulriksen) on Github.
Thanks!
Closes: #459
Co-authored-by: Gabriel Filion <gabriel@koumbit.org>
# Rationale
TLSv1.2 has been out for more than 10 years, and is now widely available. TLSv1.0 and TLSv1.1 are known to be unsufficient for a few years and have been officially deprecated by the IETF recently.
TLSv1.3 is starting to be widely available, however it had implementation bugs, such as https://github.com/proftpd/proftpd/issues/959. This is fixed upstream, but fixed versions are not available in Debian 10 yet.
# Changes
* ProFTPd now defaults to TLSv1.2
* Add a comment for suggesting other values like TLSv1.3, but with a comment about buggy versions
* Add a comment for downgrading to deprecated TLSv1 TLSv1.1
hook_updatedomains_dns_{add,del} have their return values checked in
m_dom::update_domains() to set the dns_result column.
When no return value is specified, the value is actually NULL and doesn't
get mapped to an integer value that is expected by the dns_result column.
As a result, the query fails silently and the DNS_ACTION column is never
updated. This causes update_domains to retry the same modification on
every run.
The sslcsr is just set to an empty string so that the query works properly.
Without it, queries fail since sslcsr does not have a default value set.
Improved the detail of the messages logged during the failure of that query as well.
By default, matomo applies a limit of 100 results to all API endpoints
that return an array. By passing filter_limit -1 all results can be
fetched in a single call for the site lists.
Ref: https://developer.matomo.org/api-reference/reporting-api
Fixes#341
When applying LIMIT X, Y the ordering before the limit and offset do
not seem to be guaranteed. For example, if you have a large number of
e-mail addresses, and you page between the same e-mail address can appear twice.
The case where this was happening there were 2-3 mail boxes and ~90 aliases.
I'm not sure if this tied somehow to the database version used, but making the
desired ordering explicit ensures that all mails will eventually be shown and
shouldn't be shown twice.