The parameter is now optional and uses the correct file. If defined, it
defines the CA certificate that would be used to verify client
certificate. Client certificate verification doesn't seem to currently
work as that requires a custom verification callback that interfaces with
GnuTLS.
By enabling the debug messages only at startup, we'll get log messages for
any daemon startup failures and we exlude the verbose parsing errors that
malformed requests cause.
By stopping the REST API before the workers and moving the shutdown to the
same worker that handles REST API requests, we prevent the hang on
shutdown. This also makes the signal handler signal-safe.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
The old hkheartbeat variable was changed to the mxs_clock() function that
simply wraps an atomic load of the variable. This allows it to be
correctly read by MaxScale as well as opening up the possibility of
converting the value load to a relaxed memory order read.
Renamed the header and associated macros. Removed inclusion of the
heartbeat header from the housekeeper header and added it to the files
that were missing it.
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.
The authentication errors were not sent as the connection was closed
immediately. The reason for this was the fact that if a client request
uploaded data with bad credentials, MaxScale would not send a response if
the connection was kept open. Closing the socket solved the hang but
caused confusing errors on the client side.
The libmicrohttpd library appears to require full processing of any data
uploaded by a client request before a request can be sent. With this
change, the clients receive proper authentication errors in all cases.
The type of the created user can now be specified with the --type option.
Expanded tests that cover the user creation. Also added a test case that
checks that basic users are only allowed to read through the REST API.
The call to MHD_basic_auth_get_username_password allocates memory for both
the password and the username.
mxs_json_add_relation leaked a reference to a JSON object by using
json_array_append instead of json_array_append_new.
The PATCH method should now be used instead the PUT method to update
resources. As PUT request bodies should represent complete resources, the
use of PUT to update resources is no longer supported.
Altered tests to use PATCH instead of PUT for updating resources.
Allowing requests to be converted to raw HTTP requests allows them to be
propagated to other instances of MaxScale. This should allow multiple
MaxScales to perform the same action in a coherent manner.
A simple clustering mechanism needs to be added to make MaxScale aware of
other instances.
The /maxscale/ resource now supports PUT requests which modify core
parameters. As not all parameters can be changed at runtime, only
modifications to parameters that support runtime configuration are
allowed.
The REST API now uses the same users as MaxAdmin network interface. This
allows them to be created with MaxAdmin.
The next step is to add user creation to the REST API.
If a request to the `/` resource is made, the API responds with an 200
OK. This is done to make it possible to use the HTTP health check
mechanism found in many cloud load balancers.
The PATCH method isn't supported in older versions of microhttpd. As this
functionality wasn't used, it can be removed until it is needed. The PUT
method already allows updates by defining complete resources so PATCH is
only an improvement, not a requirement.
The actual list of headers is not known when the request is first
generated. This prevents the headers from being generated in admin.cc
which handles things on a lower level.
The moving of the header generation is done with the OPTIONS method in
mind. This header needs to be generated inside the RootResource class
which manages the navigation of the resources.
The data was not processed correctly and instead an error was sent to the
client as soon as the request arrived.
Created a class that somewhat abstracts the internals of the client
request processing.
