hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update MariaDBMonitor and PAM authenticator documentation

Browse Source
This commit is contained in:
Esa Korhonen
2019-05-28 12:45:57 +03:00
parent d88846fab4
commit 5a5d625b15
2 changed files with 13 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/Authenticators/PAM-Authenticator.md
View File

@ -92,7 +92,7 @@ generating the Unix user and password should be enough.
## Implementation details and limitations
The PAM general authentication scheme is difficult for a proxy such as MaxScale.
The general PAM authentication scheme is difficult for a proxy such as MaxScale.
An application using the PAM interface needs to define a *conversation function*
to allow the OS PAM modules to communicate with the client, possibly exchanging
multiple messages. This works when a client logs in to a normal server, but not
@ -101,25 +101,22 @@ MaxScale to successfully log into the servers, the messages and answers need to
be predefined. This requirement denies the use of more exotic schemes such as
one-time passwords or two-factor authentication.
The current version of the MaxScale PAM authentication module only supports a
The MaxScale PAM authentication module only supports a
simple password exchange. On the client side, the authentication begins with
MaxScale sending an AuthSwitchRequest packet. In addition to the command, the
packet contains the client plugin name `dialog`, a message type byte `4` and the
message `Password: `. In the next packet, the client should send the password,
which MaxScale will forward to the PAM API running on the local machine. If the
password is correct, an OK packet is sent to the client. No additional
PAM-related messaging is allowed, as this would indicate a more complicated
authentication scheme.
password is correct, an OK packet is sent to the client. If the local PAM API asks
for additional credentials as is typical in two-factor authentication schemes,
authentication fails. Informational messages such as password expiration
notifications are allowed. These are simply printed to the log.
On the backend side, MaxScale expects the servers to act as MaxScale did towards
the client. The servers should send an AuthSwitchRequest packet as defined
above, MaxScale responds with the password received by the client authenticator
and finally backend replies with OK.
## SSL support
PAM Authenticator supports SSL connections from client to MaxScale, but not from
MaxScale to backends.
and finally backend replies with OK. Informational messages from backends are
only printed to the info-log.
## Building the module

9
Documentation/Monitors/MariaDB-Monitor.md
View File

@ -360,10 +360,11 @@ following:
1. Prepare the old master for demotion:
1. Stop any external replication.
2. Enable the *read\_only*-flag to stop writes.
3. Disable scheduled server events (if event handling is on).
4. Run the commands in `demotion_sql_file`.
5. Flush the binary log (FLUSH LOGS) so that all events are on disk.
2. Kill connections from super-users since *read\_only* does not affect them.
3. Enable the *read\_only*-flag to stop writes.
4. Disable scheduled server events (if event handling is on).
5. Run the commands in `demotion_sql_file`.
6. Flush the binary log (FLUSH LOGS) so that all events are on disk.
2. Wait for the new master to catch up with the old master.
3. Promote new master and redirect slaves as in failover steps 3 and 4. Also
redirect the demoted old master.