The number of arguments to createListener was incremented but the maximum
count was not. Also fixed the parameter types for createListener and
alterServer.
The server runtime alteration was broken by commit
c850336199c3c19508a3d280fb7000291d66b80c when it increased the maximum
argument count of the `alter server` command to 14.
Servers in MaxScale can encrypt the connections without client keys and
certificates. As keys and certificates are no longer required, the CA
certificate must always be initialized.
When a listener is created at runtime or SSL is being enabled for an
already created listener, the ssl_verify_peer_certificate parameter can
now be defined.
As the object name formatting is automated, so should the formatting of
object names in arguments. This also makes 2.2 backwards compatible with
2.1 commands.
The internal header directory conflicted with in-source builds causing a
build failure. This is fixed by renaming the internal header directory to
something other than maxscale.
The renaming pointed out a few problems in a couple of source files that
appeared to include internal headers when the headers were in fact public
headers.
Fixed maxctrl in-source builds by making the copying of the sources
optional.
If a module command returns a json object, it will always be
returned to the caller, irrespective of whether the command
itself succeeded or not.
Otherwise, if the command failed and if the module command has
set an error message, that error message will be returned as a
json object containing the error message.
If a module command returns a json object, it will always be
returned to the caller, irrespective of whether the command
itself succeeded or not.
Otherwise, if the command failed and if the module command has
set an error message, that error message will be returned as a
json object containing the error message.
Since the module command interface was expanded to include a JSON output
parameter, there is no longer a need for an output DCB. As the JSON can be
printed by both maxadmin and the REST API, this allows the removal of
explicit output formatting in module commands.
The failover command is simulated by executing a call to /usr/bin/echo
with all possible monitor parameters. This allows testing of the failover
mechanism without actually using the failover command.
The `script_timeout` and `journal_max_age` parameters weren't handled in
the monitor alteration code.
Also added missing documentation to maxadmin help output for
`alter monitor`.
The `add user` and `enable account` commands create fully privileged
administrative users like they did in 2.1. This makes the addition of
read-only users backwards compatible.
Updated and expanded the documentation on administrative interface
users. Added entries into the release notes as well as the upgrading
document about relevant changes between 2.1 and 2.2.
Removing the last admin account is now forbidden. This should prevent most
cases where users could lock themselves out of the administrative
interface.
This change does allow a non-root network user to be the last admin
account. In practice this does not prevent the root user from gaining
access to maxadmin. Access can be gained by removing the users file and
restarting MaxScale or by editing the users file by hand.
MaxAdmin can now create basic users for both network and UNIX domain
socket use. Currently the basic and admin types have the same permissions
in maxadmin but for the REST API, only admin accounts can modify MaxScale.
The users are now stored as an array of JSON objects. Legacy users are
automatically upgraded once they are loaded and a backup of the original
users file is created.
Removed the password parameter from the `remove user` maxadmin command as
well as all of the relevant functions. Requiring that an administrator
knows the password of the account to be deleted is not a sound requirement
now that, at least in theory, two types of accounts can be created.
If a destroyed monitor is created again, it will be reused. This should
prevent excessive memory growth when the same monitor is created and
destroyed again.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.
The module commands can now produce JSON formatted output which is passed
to the caller. The output should conform to the JSON API as closely as
possible.
Currently, the REST API wraps all JSON produced by module commands inside
a meta-object of the following type:
{
"meta": <output of module command>
}
This allows the output to be JSON API conformant without modifying the
modules and allows incremental updates to code.
The `monitoruser` and `monitorpw` parameters were mislabeled as `monuser`
and `monpw`. To allow backwards compatibility, the `monuser` and `monpw`
still work as aliases for the correct commands.
