MariaDB-Client-Zertifkate, nur für einen bestimmten User

jmar83

SQL-Guru
Beiträge
146
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. ;-)
 
Zuletzt bearbeitet:
Werbung:
hab jetzt nur quer gelesen, aber offenbar willst Du, daß 'mysql -h localhost' ohne SSL-Gedöhns geht. Was passiert, wenn Du '-h localhost' wegläßt? Dann verbindet er sich via *NIX-Socket, vielleicht greift dann SSL nicht.

Nur mal so als Schuß aus der Hüfte, ich nix MySQL ...
 
Danke aber das geht leider auch nicht.

Das hier alles nutzt mir relativ wenig , wie man für spezifische User das einrichtet, wenn dann plötzlich der root-Account damit "verseucht" ist: Securing Connections for Client and Server

...oder gibt das, was man bei der MariaDB-Konfig im Client-Abschnitt festlegt nur für die MySQL-eigenen Kommandoteilen-Tools wie `mysql` ?


Die Client-Abschnitte in der Konfig-Datei heissen evtl.:

"Verwende mit den MariaDB-eigenen-Kommandozeilen-CLIENT Tools (mysql, mysqldmp etc.) immer SSL mit den angegebenen Zertifikaten, egal was mit dem nun Zielsystem ist"

und NICHT

"Erwarte als Server immer einen Client, der diese Zertifikate einsetzt" ??


-> Vielleicht läuft deshalb auch der Windows-Client "HeidiSQL" weiter ohne zu meckern, da er über SSH (REMOTE_IP:22) dann direkt auf localhost:3306 geht ..?
 
Also grunsätzlich wird das bei MariiaDB/MySQL als auch bei PostreSQL über die darunterliegende OpenSSL
Bibliothek gemanaged und die unterstützt Peer Authentication via Client Side SSL-Zertifikat (x509 Standard).

Bedingung ist immer, dass das DB-Server SSL-Certifificate und sein Private Key von der selben Certification Authority (CA) signiert wurden als auch das Client SSL-Zertifikat. Wenn diese Bedingung erfülkz
ist, muss OpenSSL den Parameter verfify Peer mitgeteilt bekommen, wie MariaDB das an OpenSSL übermittelt müsste in den Manpages stehen.
 
Ja, aber was mich irritiert, ist die Tatsache dass z.B. "HeidiSQL" (=Windows-MySQL-Frontend, welches ich über einen SSH-Tunnel verwende um mich als `root@localhost/127.0.0.1` einzuloggen) ABSOLUT KEINEN STRESS MACHT von wegen X509-Client-Zertifikaten beim `root`-Account.

Also scheinen sich doch die [maridb-client]- sowie [maridb-client-VERISON]-Abschnitte offenbar eben rein auf die MariaDB-eigenen, lokal installierten Client-Tools (wie `mysql` oder `mysqldmp` oder so) zu beziehen... und dort wird dann fälschlicherweise das Client-Zertifikat verwendet welches eigentlich für die andere remote-Cluster-Maschine vorgesehen ist (und nicht für die lokale laufende Instanz auf 0.0.0.0 oder 127.0.0.1/localhost oder wie auch immer) verwendet.

Also Raus mit dem ganzen Karsumpel unter [mariadb-client] sowie [mariadb-client-VERSION] in der Datei `/etc/mysql/mariadb.conf.d/50-server.cnf` !!!

(Aber natürlich nur die Client-Sachen! ;-))

Ich generiere die Zertifikate alle nacheinander, zuerst die Stamm-Zertifikate und daraus die anderen (Server und Client); die Generierung klappt soweit gut. (Was aber nicht heissen muss, dass dabei die Parameter alle richtig angewendet sind damit es läuft - klar....)

Ich musste aber auch noch dafür sorgen, dass die Parameter zur Zertifikats-Generierung die gleiche "Schnittmenge" hatten auf beiden Servern. Weil diese teilweise anders reagieren. Lokal haben wir Debian "Stretch" 9 mit MariaDB 10.x, remote bei Strato haben wir Ubuntu 18.0.x LTS mit Plesk "Obsidian" 18.0.x sowie MariaDB 10.y.

Zwischen `x` und `y` in der Version von MariaDB klafft keine grosse Differenz - ist mir aktuell nicht bekannt (müsste mich kurz in der Firma einloggen) aber der Master-Master-Cluster macht ja soweit keinen Stress und läuft gut. Auf beiden Servern ist die MariaDB-Instanz an 0.0.0.0 gebunden..

- ...und nur der "replication_server_x"-Benutzer darf sich von aussen her einloggen.
-> Dieser hat ein 24-stelligenes Kennwort
- Zusätzlich ist diesem Benutzer hinterlegt, dass der Client (=Cluster-Gegenport) nur diese eine bestimmte (seine eigene) IP haben darf. Also: replication_server_1-Benutzer-Account akzeptiert nur die IP vom Replikationsserver 2, und der replication_server_2-Benutzer-Account akzeptiert nur die IP vom Replikationsserver 1.
- Zusätzlich soll nur für jeweils diese Benutzer (resp. Verbindung) eine Verschlüsselung verlangt werden. (`GRANT ... REQUIRE X509`)



(Eigentlich ziemlich `paranoid` absichert... Man könnte es noch besser machen und auf IP-Ebene mit `iptables` die beiden Gegenpart-IPs whitelisten, andernfalls ergibt ein `telnet x.x.x.x 3306` von einer nicht-zugelassenen IP halt eine Antwort à la "client ip not permitted" oder sowas wie mir schon mal aufgefallen ist... Mit einer iptables-Whitelist auf Port 3306 eingehend würde dann gar nix mehr gehen wenn die IP nicht dementsprechend ist)

Und so stellt sich auch keine Frage nach VPN... das ist relativ kompliziert aufzubauen unter Linux soviel ich weiss (unter Window$ sind's wohl ein paar Mausklicks?) und ich muss mir auch nicht die Frage stellen welcher der beiden Cluster-Teilnahmer nun der Server, und welcher der Client ist. Die gleiche Fragestellung würde ja ebenfalls bei einem SSH-Tunnel auftreten...

Da beim Master-Master-Cluster beide Teilnehmer sich auf "gleicher Ebene" befinden (Beide Master und Slave gleichzeitig) und sich gegenseitig bei einander einloggen ist es so schön "symmetrisch"... (Saubere Sache würd ich meinen! ;-))


Das das läuft ja soweit sehr stabil, wenn nur das Zertifikatsproblem nicht wäre...:-(

Zur Generierung habe ich ein Shell/Bash-Skript gemacht:

Das Skript tut die Client-Zertis dann erst in einen lokalen Ordner (/etc/mysql/client_cert) und nach dem erfolgreichen Hochladen auf den anderen Server (nach /etc/mysql - habe gehört der "AppArmor"-Dienst verlangt das so, also NUR diesen Pfad. Des weiteren MÜSSEN diese dann (eigentlich alle, nicht nur die Client-Zertifikate) den Besitzer mysql haben (chmod mysql:mysql ...) und SOLLTEN (aus Sicherheitsgründen) nur über die Berechtigung 0400 verfügen (=nur lesen für den Benutzer "mysql"... nur Benutzer, nix "Gruppe" und auch nix "Andere"). Nach dem erfolgreichen hochladen der Client-Zertifikate auf den anderen Server wird der lokale tempöräre Pfad `/etc/mysql/client_cert` wieder geleert.

Und auf dem anderen Server macht man dann genau das gleiche. Irgendwelche "vertrauenswürdige" / offizielle Zertifikats-Herausgeber (Let's encrypt oder was kommerzielles) scheint man dabei nicht nutzen zu müssen - besser gesagt: Es wird offenbar kein Parameter verlangt, welcher die Nutzung von selbst erstellten Zertifikaten explizit erlaubt. (Eigentlich alle Anleitungen im Netz laufen darauf hinaus, selbst die Zertifizierungsstelle zu spielen...)

Wenn ich irgendwelche Zertifikate selbst erstelle...

- dann wähle ich immer eine Gültigkeitsdauer von 1 Tag, damit es sofort abläuft und auf allen Systemen nach 1 Tag den gleichen Zustand hat was den Ablauf betrifft = abgelaufen...
Ein wenig off-topic, aber ein praktisches Beispiel: Dies z.B. auch bei unserer Remote-Tastatur für unser Haus-Automations-System (z.B. um eine Tür öffnen per PIN)...
Das Java-Programm, welches sich nachdem user-Autologin in der Raspbian-Konsole startet und diese per Linux-tty-Befehl in den sog. "non-blocking Mode" versetzt (Java kann das leider selber nicht) und die Tastatureingaben abfängt. U.A. Mit konfigurierbarem "Abschlusszeichen" (analog Enter-Taste) wie `*` oder `#` da numerische Keypads für den praktischen Einsatz vorgesehen sind. (=Keine direkte Möglichkeit für Ctrl-Alt-Del oder Ctrl-C (könnte aber abgefangen / ignoriert werden so wie es der uralt-Editor `ed` unter Linux auch macht), oder eben Ctrl-D - dies kann dann nicht mehr abgefangen werden nach meinem Kenntnisstand.) Da müssen dann beim Java-HTTPS-Client-Code ein einer Instanz der Klasse "WeakTrustSecurityManager" paar Funktionen als "anonyme Klasse" mit leer (solche ohne Rückgabewert = void) oder null (solche mit Rückgabewert in Form einer Klassen-Instanz) überschreiben werden.
 
Das ist das Shell-Skript. Klar, könnte noch optimiert werden. Und das dumme `lftp`-Ding (welches auch SFTP kann, mehr oder weniger, was aktuell auch so verwendet wird) ist nicht mal in der Lage, ein remote `chown` zu machen!!

(Wenn ich das gewusst hätte, dann hätte ich es von Anfang an mit den Linux-Bordmitteln (=SSH/SCP) versucht. Denke der ssh-Befehl hätte gereicht, mit der richtigen Befehlskombination (ssh ... | ANDERER_BEFEHL, also pipen oder so?) und/oder den richtigen Parametern hätte ich damit sicher auch nen Upload über SSH/SCP hingekriegt und wäre anschliessend auch fähig gewesen, auf dem anderen Server per SSH das `chown mysql:mysql /etc/mysql/*.pem` auszuführen... aber egal, jetzt bleibt halt weiterhin lftp im Einsatz, und anschliessend wird noch ein PHP-Skript (aber nicht als Webanwendung! ;-) ausgeführt welches über die Library `phpseclib` sich remote einloggen und halt so das `chown mysql:mysql /etc/mysql/*.pem` macht, na ja, *** bastel, bastel *** ... , aber es funktioniert ja soweit zuverlässig und stabil...)



```
#!/bin/bash
set -e > /dev/null 2>&1 && set +x > /dev/null 2>&1;
FILE="$(basename "$(test -L "$0" && readlink "$0" || echo "$0")")";
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )" && chmod +x "$DIR/$FILE";
rm -f /etc/mysql/client_cert/*;
rm -f /ca-cert.pem && rm -f /ca-key.pem && rm -f /server-cert.pem && rm -f /server-key.pem && rm -f /server-key-pkcs8.pem && rm -f /server-req.pem;
cd /etc/mysql;
C="CH";
ST="Bern";
L="Thun";
O="Hinz & Kunz AG";
OU="Development Department";
CN="hinz-kunz-ag.ch";
echo "";
openssl genrsa 2048 > ca-key.pem 2>/dev/null;
openssl req -new -x509 -nodes -days 1 -subj "/C=$C/ST=$ST/L=$L/O=$O/OU=$OU/CN=$CN" -key ca-key.pem > ca-cert.pem 2>/dev/null || :;
openssl req -newkey rsa:2048 -x509 -days 1 -subj "/C=$C/ST=$ST/L=$L/O=$O/OU=$OU/CN=$CN" -nodes -keyout server-key-pkcs8.pem > server-req.pem 2>/dev/null || :;
openssl rsa -in server-key-pkcs8.pem -out server-key.pem > /dev/null 2>&1;
openssl x509 -in server-req.pem -signkey ca-key.pem -days 1 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem 2>/dev/null;
openssl req -newkey rsa:2048 -days 1 -subj "/C=$C/ST=$ST/L=$L/O=$O/OU=$OU/CN=$CN" -nodes -keyout ./client_cert/client-key-pkcs8.pem > ./client_cert/client-req.pem 2>/dev/null || :;
openssl rsa -in ./client_cert/client-key-pkcs8.pem -out ./client_cert/client-key.pem > /dev/null 2>&1;
openssl x509 -req -in ./client_cert/client-req.pem -days 1 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > ./client_cert/client-cert.pem 2>/dev/null;
chmod 0400 /etc/mysql/*.pem && chown mysql:mysql /etc/mysql/*.pem && chmod 0400 /etc/mysql/client_cert/*.pem && chown mysql:mysql /etc/mysql/client_cert/*.pem;
echo "Created files in directory '/etc/mysql': " && echo "";

ls -ll *.pem && echo "";
QOF=$(ls *.pem | wc -l);
if [ $QOF -eq 6 ] || [ $QOF -eq 10 ]; then
NSF=$(ls -ll *.pem | grep 'root 0' || :);
if [ $NSF ]; then
echo "FAILED: One or more files are empty!" && echo "" && exit 1;
else
echo "SUCCESSFUL: There are $QOF files in '/etc/mysql' and none of them are empty.";
COLOR_RED_VALUE='\033[0;31m' && COLOR_DEFAULT_VALUE='\033[0m';
printf "${COLOR_RED_VALUE}--> IMPORTANT: 10 files = WITH the client certificates, they was generated on the remote server and uploaded to this local filesystem. ${COLOR_DEFAULT_VALUE}\n";
printf "${COLOR_RED_VALUE} 6 files = WITHOUT the client certificates, they are still missing. Please create and upload them on the other server. ${COLOR_DEFAULT_VALUE}\n" && echo "";
fi;
else
echo "FAILED: There are only $QOF files in '/etc/mysql'" && echo "" && exit 1;
fi;

cd /etc/mysql/client_cert;
echo "Created files in directory '/etc/mysql/client_cert': " && echo "";

ls -ll *.pem && echo "";
QOF=$(ls *.pem | wc -l);
if [ $QOF -eq 4 ]; then
NSF=$(ls -ll *.pem | grep 'root 0' || :);
if [ $NSF ]; then
echo "FAILED: One or more files are empty!" && echo "" && exit 1;
else
echo "SUCCESSFUL: There are $QOF files in '/etc/mysql/client_cert' and none of them are empty." && echo "";
fi;
else
echo "FAILED: There are only $QOF files in '/etc/mysql/client_cert'" && echo "" && exit 1;
fi;

echo "";
cd /etc/mysql;

IP=$(ifconfig $(/sbin/ifconfig eth0 2>/dev/null | awk -F\: '/^e/ {print $1;}' ) | awk '/inet/ {print $2; exit;}');
if [[ "$IP" == *"127.0.0.1"* ]]; then
IP=$(/sbin/ifconfig venet0:0 | grep 'inet' | cut -d: -f2 | awk '{print $2; exit;}');
fi;
IP=$(echo $IP | awk -F\, '{gsub(/[ \t]+$/, "", $IP); print $IP;}');
HOST=$(cat /dev/null);
# Check server IP address to get other server IP address {
# x.x.x.x = server.net, y.y.y.y = server.li
# x = Prod. Server # Lokaler Prod-Server bei uns vor Ort
# y = Dev. Server # Lokaler Dev-Server bei uns vor Ort - aktuell zum Aufbau und Test des Clusters genutzt
if [ "$IP" == "x.x.x.x" ] || [ "$IP" == "y.y.y.y" ]; then
HOST="z.z.z.z"; # Remote-Master/Master-Cluster-Maschine bei Strato (VServer), aktuell Master-Cluster-Bestandteil der Dev-Umgebung, später Prod.!!
else
if [ "$IP" == "z.z.z.z" ]; then
HOST="y.y.y.y"; # Wenn man sich auf dem Remote-Server bei Strato befindet, dann verteile das Client-Zertifikat aktuell (noch) auf unseren lok. Dev. Server, später dann auf Prod. (x.x.x.x) umstellen!!
fi;
fi;
# } Check server IP address to get other server IP address
read -p "Please enter SFTP server: " -i "$HOST" -e REMOTE_SERVER;
read -p "Please enter SFTP username: " -i root -e REMOTE_USERNAME;
unset REMOTE_PASSWORD;
prompt="Please enter SFTP password: ";
while IFS= read -p "$prompt" -r -s -n 1 char
do
if [[ $char == $'\0' ]]; then
break;
fi;
prompt='*';
REMOTE_PASSWORD+="$char";
done;
echo "";
if [ ! $REMOTE_SERVER ]; then
echo "You need to set the host name."
fi;
if [ ! $REMOTE_USERNAME ]; then
echo "You need to set the username."
fi;
if [ ! $REMOTE_PASSWORD ]; then
echo "You need to set the password.";
fi;
#lftp -p 22 -u $REMOTE_USERNAME,$REMOTE_PASSWORD sftp://$REMOTE_SERVER > /dev/null 2>&1 << EOF
lftp -p 22 -u $REMOTE_USERNAME,$REMOTE_PASSWORD sftp://$REMOTE_SERVER << EOF
# Set connection parameters {
set sftp:auto-confirm yes;
set ssl:verify-certificate no;
set net:timeout 3;
set ftp:passive-mode true;
set ftp:use-mode-z true;
set ftp:mode-z-level 9;
set ftp:use-allo true;
# } Set connection parameters

# Upload locally saved, self-generated certificates for other clients {
mirror -R --allow-chown /etc/mysql/client_cert /etc/mysql;
# } Upload locally saved, self-generated certificates for other clients

# Remove locally saved, self-generated certificates for other clients {
!rm -f /etc/mysql/client_cert/*;
# } Remove locally saved, self-generated certificates for other clients

# Set remote permissions {
chmod 0400 /etc/mysql/client-cert.pem;
chmod 0400 /etc/mysql/client-key.pem;
chmod 0400 /etc/mysql/client-key-pkcs8.pem;
chmod 0400 /etc/mysql/client-req.pem;
# } Set remote permissions

# Close SFTP connection after upload {
quit;
# } # Close SFTP connection after upload
EOF

# Set remote files owner with SSH, 'lftp' is not able to do a remote chown {
php /etc/mysql/changeperm.php -h $REMOTE_SERVER -u $REMOTE_USERNAME -p $REMOTE_PASSWORD
# } Set remote files owner with SSH, 'lftp' is not able to do a remote chown

echo "";
```

...Zertifikats-Angaben habe ich geändert wie auch IPs. Und dazu noch ein paar Kommentare ergänzt, evtl. kann ja jemand mit dem Skript man was anfangen - wenn eine ähnliche Lösung gesucht wird?
 
Wie lassen sich die doofen Smilies im Quelltext ausschalten? (Gut, ab und zu verwende ich ja auch Emoticons, aber im Quelltext haben sie nix verloren - auch nicht in Kommentaren, Programmieren ist schliesslich ne sachlich-rationale Angelegenheit...)

Nachtrag: Irgendwo habe ich gesehen, dass man bei den SLAVE-/MASTER-Befehlen was an Zertifikats-Pfaden mitgeben kann. Werde der Sache dann nachgehen...
 
Hallo zusammen

So, nun ist (leider) wieder Montag und ich sitze am Arbeitsplatz und das Thema `MariaDB-Client-Zertifkate, nur für einen bestimmten User` ist wieder die aktuelle Hauptbeschäftigung...


Vorher würde ich aber gerne noch folgendes klären, bevor ich weitermache und es mir immer wieder irgendwelche Codes und Quelltexte "verhunzt" mit den Emoticons:

Eigentlich ist es immer noch die gleiche Frage wie im vorletzten Post: ein `p` nach einem `:` (und nicht nur in diesem Fall, gibt ja noch andere) verursacht z.B. dieses Emoticon hier: https://www.datenbankforum.com/styles/default/xenforo/smilies/tongue.png

Wie lässt sich das nun ausschalten?

1.) In den Profileinstellungen (also "global") sehe ich nichts
2.) Beim posten des Beitrga unter "Weitere Einstellungen" sehe ich ebenfalls keine mir dafür passend scheinende Option


Hauptfrage: Ist es überhaupt möglich, dieses Verhalten zum ändern / zu beeinflussen?

Falls die Antwort "NEIN" lautet, so wäre ich froh um eine kurze Bestätigung falls es wirklich so ist...

Vielen Dank, bereits im Voraus! :-)
 
Space reintun in Quellcode als Workaround oder wie...?

Damit würde das "SET SFTP_OPTION x" aber fehlschlagen, wie ich in Erinnerung (?) habe.

Wollte den Code ein wenig formatieren, dabei ist mir aufgefallen:

Das geht (funktioniert was das SSH-Interpreter betrifft), also alle Doppelpunkte untereinander. Aber kein Space links und rechts davon. Und auch wenn vor dem Doppelpunkt eine untersch. Anzahl an Zeichen für den Attributs-Namen wäre und dann, je nach dem, nach dem `set` > 1 Leerzeichen notwendig wäre:

set sftp:auto-confirm yes;
set ssl:verify-certificate no;
set net:timeout 3;
set ftp:passive-mode true;
set ftp:use-mode-z true;
set ftp:mode-z-level 9;
set ftp:use-allo true;



Das geht (wenn ich mich richtig erinnere) nicht:

set sftp:auto-confirm yes;
set ssl :verify-certificate no;
set net :timeout 3;
set ftp :passive-mode true;
set ftp :use-mode-z true;
set ftp :mode-z-level 9;
set ftp :use-allo true;



Aber wenn das dann (was zu erwarten ist) zum Problem wird, gibt ja noch verschiedene solche `Text-Paste`-Webseiten... irgendeine Lösung gibt es für alles, aber es wäre sicher von Vorteil wenn man hier im Forum solche Einstellungen beeinflussen könnte.

Daher @admin: Verbessungsvorschlag von mir!! ;-)
 
set sftp: auto-confirm yes;
set ssl: verify-certificate no;
set net: timeout 3;
set ftp: passive-mode true;
set ftp: use-mode-z true;
set ftp: mode-z-level 9;
set ftp: use-allo true;
 
Werbung:
OK, für's Forum scheint's damit zu klappen - auch wenn der Code so syntaktisch ungültig ist. Aber manchmal muss man halt Kompromisse eingehen, so ist das im Leben...;-)

Eine andere Variante wäre, ein Screenshot vom Quellcode zu machen, und diesen hier als Bild zu posten. Manchmal muss man halt auch etwas kreativ sein...
 
Zurück
Oben