Authenticators now have a similar mechanism to the `router_options`
parameter which enables configurable authentication.
The authenticators also have a new initialize entry point which is similar
to the createInstance entry point of the filters and routers. The value of
`authenticator_options` is passed as a parameter to this function. The
return vaulue of the `initialize` entry point is passed to the `create`
entry point.
The MySQLCommon library contains functions used by both the protocol and
authenticator modules. The contents of the modutil.c file could also be
moved to this file if the functions in that file are only used by modules
and not the core.
The create and destroy entry points allow authenticators to store data in
the DCB. This data is not shared by other DCBs related to the same
session.
The plugin_name entry point wasn't really useful as the plugins would
still need to send a AuthSwitchRequest packet if they wanted to change the
authentication mechanism.
The authentication for backend connections is now done in the
MySQLBackendAuth module. This is also the default authentication module
for backend connections created by MySQLBackend.
The backend responses are now read in one place and the functions just
read the data. The protocol level will now handle the packet gathering
process and the authentication part just inspects the data.
Backend connections now load authenticators when they are being
connected. In the future, this enables the use of authentication modules
for backend connection.
The DCB error messages now log the type of the DCB and the remote address
in addition to the system error message. The file descriptor and memory
address are no longer printed in the error message as they are not useful
to the end user. The fd and address are now logged at debug level with a
more verbose error message.
As errors and warnings are throttled, there is a need for being able
to log severe errors without ever having them throttled (e.g. when
logging the stack in conjunction with a crash).
MXS_ALERT should only be used in a context where the process is known
to be going down, either via crash or explicit exit.
The mysqlmon simple failover mode allows it to direct write traffic to a
secondary node. This enables a very simple failover mode with MaxScale
when it is used in a two node master-slave setup.
The canonical form of the query should ignore changes in whitespace as the
semantics of the query stays the same regardless of the amount of
whitespace.
The MYSQL_* authentication return codes are now in gw_authenticator.h so
that all authenticators can use them. Also dropped the MYSQL_ prefix from
the return codes and added AUTH_INCOMPLETE for a generic
authentication-in-progress return code.
MaxScale shouldn't require the service and monitor user checks. It makes
sense to disable the checks to speed up the startup process when the user
knows that the permissions are OK.
Session command responses with multiple packets could be spread across
multiple, non-contiguous buffers. If a buffer contained a complete packet
and some extra data but it wasn't contiguous, the debug assertion in
gwbuf_clone_portion would fail. With release builds, it would cause
eventual out-of-bounds memory access when the response would be sent to
the client.
- Single entry/single exit.
- Variables declared as they are needed.
- The GWBUF_EMPTY check removed as it only looks at the first buffer
in a chain. That is, if there had been a non-empty chain where the
first buffer is empty, the function would incorrectly have reported
that the buffer contains no packet.
- Documentation updated.
The `detect_stale_slave` functionality used to only work when MaxScale had
the knowledge that a master server has existed and that replication was
working at some point in time. This might be a "safe" way to do it in
regards to staleness of the data but in practice it is preferrable to
always allow slave to be used for reads.
This change adds the missing functionality to the monitor by assigning
slave status to all servers which are configured as replication slaves
when no master can be found.
The new member variable that was added to the SERVER should be removed in
2.1 where the server_info offers the same functionalty without "polluting"
the SERVER type.
If a relay master server is found in the replication tree, it should not
get the master status. Previously all master servers were assigned the
master status regardless of their depth in the replication tree.
By comparing the depth value of each potential master, the monitor can
find the right master at the root of the replication tree.
The mysqlmon now supports proper detection of multi-master topologies by
building a directed graph out of the monitored server. If cycles are found from
this graph, they are assigned a master group ID. All servers with a positive
master group ID will receive the Master status unless they have `@@read_only`
enabled.
This new functionality can be enabled with the 'multimaster' boolean
parameter.
Although claimed in the output of "--help", the long option
"--execdir" was not supported. Support for that now added.
The long options have now also been sorted in the same order
as the options are displayed by the help, to make it easy to
check that everything is there.
Further, the description column of the output of --help has
been aligned.
In the configuration section of services and monitors, the
password to be used can now be specified using 'password'
in addition to 'passwd'.
If both are provided, then the value of 'passwd' is used. That
way there cannot be any surprises, should someone for whatever
reason currently (in 1.4.3 an invalid parameter will not prevent
MaxScale from starting) have a 'password' entry in his config file.
In the next release 'passwd' can be deprecated and in the release
after that removed.
The service start retry mechanism mistakenly returned an error when a
service failed to start but a retry was queued. This caused MaxScale to
stop whenever a service failed to start.
dcb_count_by_usage did not iterate the list properly and would get stuck on the
first inactive DCB. Since this function is only called by maxinfo, it would be
the only one to get stuck.
In the case of a Unix domain socket, the required buffer size may
in principle be up to PATH_MAX, so better to explicitly ensure that
there's enough space.
It's now possible to use both a Unix domain socket and host/port
when connecting with MaxAdmin to MaxScale.
By default MaxAdmin will attempt to use the default Unix domain
socket, but if host and/or port has been specified, then an inet
socket will be used.
maxscaled will authenticate the connection attempt differently
depending on whether a Unix domain socket is used or not. If
a Unix domain socket is used, then the Linux user id will be
used for the authorization, otherwise the 1.4.3 username/password
handshake will be performed.
adminusers has now been extended so that there is one set of
functions for local users (connecting locally over a Unix socket)
and one set of functions for remote users (connecting locally
or remotely over an Inet socket).
The local users are stored in the new .../maxscale-users and the
remote users in .../passwd. That is, the old users of a 1.4
installation will work as such in 2.0.
One difference is that there will be *no* default remote user.
That is, remote users will always have to be added manually using
a local user.
The implementation is shared; the local and remote alternatives
use common functions to which the hashtable and filename to be
used are forwarded.
The commands "[add|remove] user" behave now exactly like they did
in 1.4.3, and also all existing users work out of the box.
In addition there is now the commands "[enable|disable] account"
using which Linux accounts can be enabled for MaxAdmin usage.
The binlogrouter requires that users are not loaded at startup. This
allows it to inject the service user into the list of valid MySQL users so
that the binlogrouter can be controlled via the listeners.
The authenticator modules now load the user data when the new loadusers
entry point is called. This new entry point is optional.
At the moment the code that was in service.c was just moved into the
modules but the ground work for allowing different user loading mechanisms
is done.
Further improvements need to be made so that the authenticators behave
more like routers and filters. This work includes the creation of a
AUTHENTICATOR module object, addition of createInstance entry points for
authenticators and implementing it for all authenticators.
Local admins are the ones accessing MaxScale on the same host
over a Unix domain socket, and who are strongly identified), and
optional remote admins are the ones accessing MaxScale potentially
over a tcp socket (potentially over the network), and who are
weakly identified.
These are completely separate and a different set of functions
will be needed for managing them. This initial change merely
renames the functions.
When a server goes into maintenance, the current state is set to
Maintenance and the previous state is left unmodified. The function which
checks for state changes uses the current and previous values and simply
compares them. Since servers in maintenance mode aren't monitored, the
function always returned true when servers were in maintenance mode.
When the state change to or from maintenance is ignored, the state change
function works. With this fix, users can safely put servers into
maintenance without having to worry about the scripts being executed. This
also allows the scripts themselves to put servers into maintenance.