Worker is now the base class of all workers. It has a message
queue and can be run in a thread of its own, or in the calling
thread. Worker can not be used as such, but a concrete worker
class must be derived from it. Currently there is only one
concrete class RoutingWorker.
There is some overlapping in functionality between Worker and
RoutingWorker, as there is e.g. a need for broadcasting a
message to all routing workers, but not to other workers.
Currently other workers can not be created as the array for
holding the pointers to the workers is exactly as large as
there will be RoutingWorkers. That will be changed so that
the maximum number of threads is hardwired to some ridiculous
value such as 128. That's the first step in the path towards
a situation where the number of worker threads can be changed
at runtime.
We need to copy some data from a AF_UNIX based listener dcb
to the accepted client dcb, to prevent assertion violation in
dcb_get_port(). Further, to be able to log the path in the case
of an authentication error we need to copy that as well.
Earlier, if a service had multiple listeners you would have had
MaxScale> show dbusers MyService
User names: alice@% ...
User names: bob@% ...
That is, no indication of which listener is reporting what. With
this commit the result will be
User names (MyListener1): alice@% ...
User names (MyListener2): bob@% ...
Further, the diagnostics function of an authenticator is now expected
to write the list of users to the provided DCB, without performing any
other formatting. The formatting (printing "User names" and appending
a line-feed) is now handled by the handler for the MaxAdmin command
"show dbusers".
The message now states the impliciations of missing permissions. If the
MaxScale user does not have the permissions to view all databases, it will
only see its own databases.
MySQLAuth requires the SHOW DATABASES privilege to see all the databases
so it should be checked that the current user has the permission. A
missing permission will cause errors that are hard to resolve.
This is used only in case of everything else fails and this lookup
is not unlikely to fail if the client comes from some machine on
an internal network.
According to customer reports collecting the statistics has a significant
impact on the performance. As we don't need that information we can just
as well turn off that.
Further, since maxscale-common now links to the sqlite3-library, no
module needs to do that explicitly.
The list of users that is used for authentication shoudl only consist of
users that do not use an explicit authentication plugin. This way
authentication fails before any connections to the backend servers are
done.
Make all modules lowercase and make module loading case
insensitive. Further, make command invocation case insensitive,
as far as the module name is conserned.
When a client connects to MaxScale and authentication fails, an error
about hostname resolution is logged. This happens because the
authentication first tries to resolve the address as an IP address, then
an IPv6-mapped-IPv4 address and finally as a hostname. If users have not
been loaded, the authentication is guaranteed to fail on the first attempt
due to the lazy loading of users.
The :memory: database was misspelled as :memory without the trailing
colon. This caused an actual on-disk database to be created instead of an
in-memory one.
The thread-local user cache removes most of the cross-thread communication
from the user authentication at the cost of increased memory use and extra
network usage when users are loaded.
If the authenticator option is enabled, no users are loaded and no errors
have occurred in the user loading process, the service credentials are
injected.
The result of the authentication should be ignored but the scramble that
is calculated as a side-effect still needs to be stored. This can be done
by altering the SQL used to get the matching row to only match on the
username, not the network address.
Also expanded the test case to cover the use of bad credentials.
Cleaned up the MaxScale version of the mysql.h header by removing all
unused includes. This revealed a large amount of dependencies on these
removed includes in other files which needed to be fixed.
Also sorted all includes in changed files by type and alphabetical
order. Removed explicit revision history from modified files.
The function should actually be in include/maxscale/protocol/mysql.h
and the implementation in MySQLCommon, but the monitors do not link
to that yet.
All MySQL related should be moved to MySQLCommon and the core
refactored so that no MySQL knowledge is needed there.
With this change, it is no longer possible that the server version
is deallocated at the very moment it is read. There is still a race,
but it's mostly harmless.
If a client connects from an IPv4 address, but the listener listens on an
IPv6 address, the client IP will be a IPv6 mapped IPv4 address
e.g. ::ffff:127.0.0.1. A grant for an IPv4 address should still match an
IPv6 mapped IPv4 address.
When users were loaded, the permissions for the service user were
checked. The conditional that makes sure the check is executed only at
startup was checking the listener's users instead of the SQLite handle
which caused all reloads of users to check the permissions.
When log messages are written with both address and port information, IPv6
addresses can cause confusion if the normal address:port formatting is
used. The RFC 3986 suggests that all IPv6 addresses are expressed as a
bracket enclosed address optionally followed by the port that is separate
from the address by a colon.
In practice, the "all interfaces" address and port number 3306 can be
written in IPv4 numbers-and-dots notation as 0.0.0.0:3306 and in IPv6
notation as [::]:3306. Using the latter format in log messages keeps the
output consistent with all types of addresses.
The details of the standard can be found at the following addresses:
https://www.ietf.org/rfc/rfc3986.txthttps://www.rfc-editor.org/std/std66.txt
