Wie haben einen MariaDB Master/Master-Cluster inkl einem Skript welches Stamm-, Client-, sowie Serverzertifikate generiert. Die Clientzertifikate werden vom Skript jeweils auf den anderen Server verteilt.
Nun:
Wenn ich in der /etc/mysql/mariadb.conf.d/50-server.cnf den Server-Part angebe, dann passiert soweit nix, es scheint optional zu sein ob der Client nun Zertifikate verwendet oder nicht.
Wenn ich aber sowas angebe, die Konfig der Client-Zertis, dann meckers das `mysql`-Konsolentool bei einer Eingabe von `mysql -h localhost -u root -p password` plötzlich:
```
# J.M., 2020-01-17 {
[client-mariadb]
#ssl = 0
#ssl-cert = /etc/mysql/client-cert.pem
#ssl-key = /etc/mysql/client-key.pem
#ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
#ssl = 0
#ssl-cert = /etc/mysql/client-cert.pem
#ssl-key = /etc/mysql/client-key.pem
#ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
```
Sicherheitshalber habe ich 2 Abschnitte gemacht, und aktuell ist auch wieder jeder Zeile auskommentiert damit's wieder geht.
Frage: Was muss ich da machen?
Ich möchte EINZING UND ALLEINE dass die Benutzer `replication_server_1` sowie `replication_server_2` die X509-Technik verwenden... alle anderen sind eh an localhost gebunden und somit nicht öffentlich.
Aber auch `replication_server_1` sowie `replication_server_2` sind nicht wirklich öffentlich `replication_server_1` akzeptiert nur die IP von Server 2, `replication_server_2` nur die von Server 1!
Um die replication_server_X-Benutzer zu erstellen, verwende ich folgende Befehl:
```
FLUSH PRIVILEGES;
DROP USER IF EXISTS 'replication_server_1'@'1.1.1.1';
FLUSH PRIVILEGES;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication_strato'@'1.1.1.1' IDENTIFIED BY 'my_password' REQUIRE X509;
UPDATE mysql.user SET authentication_string = PASSWORD('my_password') WHERE User = 'replication_strato';
FLUSH PRIVILEGES;
```
resp.
```
FLUSH PRIVILEGES;
DROP USER IF EXISTS 'replication_server_2'@'2.2.2.2';
FLUSH PRIVILEGES;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication_intro'@'2.2.2.2' IDENTIFIED BY 'my_password' REQUIRE X509;
UPDATE mysql.user SET authentication_string = PASSWORD('my_password') WHERE User = 'replication_intro';
FLUSH PRIVILEGES;
```
(CREATE USER scheint Mariadb 10.x nicht zu unterstützen, deshalb GRANT; und das nachträgliche UPDATE ist aus Kompatibilitätsgründen besser habe ich festgestellt. Und ein paar mal FLUSH PRIVILEGES schadet sicher auch nicht.)
Nun: Warum zum Teufel kann ich mich dann plötzlich lokal nicht mehr als root per `mysql -h localhost -u root -p my_password` einloggen mit diese Konfig, WTF!!
Der root-Benutzer ist schliesslich NICHT mit "REQUIRE X509" geflaggt!!!!!!!!!!!!!!!!!!!!
```
# J.M., 2020-01-17 {
[client-mariadb]
ssl = 1
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
ssl = 1
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
```
oder auch
```
# J.M., 2020-01-17 {
[client-mariadb]
ssl = 0
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
ssl = 0
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
```
(Habe zuerst gedacht `ssl = x` bestimmt ob das Zeugs in jedem Fall ZWANGSLÄUFIG angewendet werden soll - also für jeden Account)
Wie kriege ich es also hin dass die Verschlüsselung nur für einen bestimmten Benutzer `mysql_replication_X` erforderlich wird.
Und komisch ist, dass das `mysql`-Konsolentool stress macht mit der Meldung "Unable to very peer checksum", das Windows-MySQL-GUI-Frontend-Tool "HeidiSQL" wiederum nicht. WTF hoch 27!!!!!!!!
Haben die Client-SSL-Einträge in der Konfig zu folge, dass auf dem lokalen System dann mit dem `mysql`-Konsolentool immer versucht wird die Client-Zertifikate (zur Verbindungsverschlüselung) zu verwenden - auch wenn dann der root halt gar nicht mit "... REQUIRE X509" geflaggt ist und das zum ganzen Stress führt.
Dann müsste ich evtl. auf diese Client-Einträge verzichten, um bei der SQL-Anweisung wo der Master-Server definiert wird irgendeinen Pfad mitliefern?
Z.B. was in der Art (Pseudocode):
```
STOP SLAVE;
RESET SLAVE;
RESET MASTER;
CHANGE MASTER TO master_host='1.1.1.1', master_port=3306, master_user='replication_strato', master_password='my_password', master_log_file='mysql-bin.000001', master_log_pos=313, ssl-cert='/etc/mysql/client-cert.pem' ssl-key='/etc/mysql/client-key.pem' ssl-ca='/etc/mysql/ca-cert.pem'
START SLAVE;
FLUSH PRIVILEGES;
EXIT;
...und dann noch in der Konsole `systemctl restart mysql` ??
```
Eben halb diesen ganzen Kran nur für diese einzelne Verbindung:
" ssl-cert='/etc/mysql/client-cert.pem' ssl-key='/etc/mysql/client-key.pem' ssl-ca='/etc/mysql/ca-cert.pem' "
Danke für die Feedbacks.
P.S.: @akretschmer: Bitte kein Postgres vorschlagen, Postgres ist im Vergleich zu MySQL ABSOLUT GENIAL, ich weiss! Basiert ja auf der "richtigen" Datenbank "Ingres" - dahinter sind wohl etwa 35 oder mehr Jahre Entwicklungszeit welche in Postgres eingeflossen sind. Wenn das nicht genau stimmt, kannst Du mich aber gerne weiter zum Thema Ingres-Postgres aufklären. ;-)
Nun:
Wenn ich in der /etc/mysql/mariadb.conf.d/50-server.cnf den Server-Part angebe, dann passiert soweit nix, es scheint optional zu sein ob der Client nun Zertifikate verwendet oder nicht.
Wenn ich aber sowas angebe, die Konfig der Client-Zertis, dann meckers das `mysql`-Konsolentool bei einer Eingabe von `mysql -h localhost -u root -p password` plötzlich:
```
# J.M., 2020-01-17 {
[client-mariadb]
#ssl = 0
#ssl-cert = /etc/mysql/client-cert.pem
#ssl-key = /etc/mysql/client-key.pem
#ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
#ssl = 0
#ssl-cert = /etc/mysql/client-cert.pem
#ssl-key = /etc/mysql/client-key.pem
#ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
```
Sicherheitshalber habe ich 2 Abschnitte gemacht, und aktuell ist auch wieder jeder Zeile auskommentiert damit's wieder geht.
Frage: Was muss ich da machen?
Ich möchte EINZING UND ALLEINE dass die Benutzer `replication_server_1` sowie `replication_server_2` die X509-Technik verwenden... alle anderen sind eh an localhost gebunden und somit nicht öffentlich.
Aber auch `replication_server_1` sowie `replication_server_2` sind nicht wirklich öffentlich `replication_server_1` akzeptiert nur die IP von Server 2, `replication_server_2` nur die von Server 1!
Um die replication_server_X-Benutzer zu erstellen, verwende ich folgende Befehl:
```
FLUSH PRIVILEGES;
DROP USER IF EXISTS 'replication_server_1'@'1.1.1.1';
FLUSH PRIVILEGES;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication_strato'@'1.1.1.1' IDENTIFIED BY 'my_password' REQUIRE X509;
UPDATE mysql.user SET authentication_string = PASSWORD('my_password') WHERE User = 'replication_strato';
FLUSH PRIVILEGES;
```
resp.
```
FLUSH PRIVILEGES;
DROP USER IF EXISTS 'replication_server_2'@'2.2.2.2';
FLUSH PRIVILEGES;
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replication_intro'@'2.2.2.2' IDENTIFIED BY 'my_password' REQUIRE X509;
UPDATE mysql.user SET authentication_string = PASSWORD('my_password') WHERE User = 'replication_intro';
FLUSH PRIVILEGES;
```
(CREATE USER scheint Mariadb 10.x nicht zu unterstützen, deshalb GRANT; und das nachträgliche UPDATE ist aus Kompatibilitätsgründen besser habe ich festgestellt. Und ein paar mal FLUSH PRIVILEGES schadet sicher auch nicht.)
Nun: Warum zum Teufel kann ich mich dann plötzlich lokal nicht mehr als root per `mysql -h localhost -u root -p my_password` einloggen mit diese Konfig, WTF!!
Der root-Benutzer ist schliesslich NICHT mit "REQUIRE X509" geflaggt!!!!!!!!!!!!!!!!!!!!
```
# J.M., 2020-01-17 {
[client-mariadb]
ssl = 1
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
ssl = 1
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
```
oder auch
```
# J.M., 2020-01-17 {
[client-mariadb]
ssl = 0
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
[client-mariadb-10.1]
ssl = 0
ssl-cert = /etc/mysql/client-cert.pem
ssl-key = /etc/mysql/client-key.pem
ssl-ca = /etc/mysql/ca-cert.pem
# } J.M., 2020-01-17
```
(Habe zuerst gedacht `ssl = x` bestimmt ob das Zeugs in jedem Fall ZWANGSLÄUFIG angewendet werden soll - also für jeden Account)
Wie kriege ich es also hin dass die Verschlüsselung nur für einen bestimmten Benutzer `mysql_replication_X` erforderlich wird.
Und komisch ist, dass das `mysql`-Konsolentool stress macht mit der Meldung "Unable to very peer checksum", das Windows-MySQL-GUI-Frontend-Tool "HeidiSQL" wiederum nicht. WTF hoch 27!!!!!!!!
Haben die Client-SSL-Einträge in der Konfig zu folge, dass auf dem lokalen System dann mit dem `mysql`-Konsolentool immer versucht wird die Client-Zertifikate (zur Verbindungsverschlüselung) zu verwenden - auch wenn dann der root halt gar nicht mit "... REQUIRE X509" geflaggt ist und das zum ganzen Stress führt.
Dann müsste ich evtl. auf diese Client-Einträge verzichten, um bei der SQL-Anweisung wo der Master-Server definiert wird irgendeinen Pfad mitliefern?
Z.B. was in der Art (Pseudocode):
```
STOP SLAVE;
RESET SLAVE;
RESET MASTER;
CHANGE MASTER TO master_host='1.1.1.1', master_port=3306, master_user='replication_strato', master_password='my_password', master_log_file='mysql-bin.000001', master_log_pos=313, ssl-cert='/etc/mysql/client-cert.pem' ssl-key='/etc/mysql/client-key.pem' ssl-ca='/etc/mysql/ca-cert.pem'
START SLAVE;
FLUSH PRIVILEGES;
EXIT;
...und dann noch in der Konsole `systemctl restart mysql` ??
```
Eben halb diesen ganzen Kran nur für diese einzelne Verbindung:
" ssl-cert='/etc/mysql/client-cert.pem' ssl-key='/etc/mysql/client-key.pem' ssl-ca='/etc/mysql/ca-cert.pem' "
Danke für die Feedbacks.
P.S.: @akretschmer: Bitte kein Postgres vorschlagen, Postgres ist im Vergleich zu MySQL ABSOLUT GENIAL, ich weiss! Basiert ja auf der "richtigen" Datenbank "Ingres" - dahinter sind wohl etwa 35 oder mehr Jahre Entwicklungszeit welche in Postgres eingeflossen sind. Wenn das nicht genau stimmt, kannst Du mich aber gerne weiter zum Thema Ingres-Postgres aufklären. ;-)
Zuletzt bearbeitet:
;
assive-mode true;
