Beim Automatisieren meiner WordPress-Umgebung bin ich über ein Problem gestolpert, das ich so nicht erwartet hatte.

Ich konnte mich plötzlich nicht mehr in MySQL einloggen – weder über phpMyAdmin noch über die CLI.
Nur noch:

sudo mysql

Nach einigem Debugging kam dann die eigentliche Ursache:

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

🧠 Das Problem: MySQL Password Policy

Neuere MySQL-Versionen erzwingen standardmäßig eine Passwort-Policy.

Das bedeutet:

• einfache Passwörter werden abgelehnt
• manchmal ohne offensichtlichen Hinweis im Workflow
• bestehende Passwörter funktionieren weiter
• neue schlagen plötzlich fehl

👉 Genau das macht es so verwirrend.

💡 Die Lösung: Automatisierte, policy-sichere Passwörter

Anstatt manuell Passwörter zu wählen, habe ich ein Skript gebaut, das:

• sichere Passwörter generiert
• diese in einer .env speichert
• konsistent von anderen Skripten genutzt werden kann

🔧 Das Skript

#!/usr/bin/env bash
set -euo pipefail

NAME="${1:-}"
NAME="${NAME%/}"
FORCE=false
PRINT=false

# --- Argument Parsing ---
for arg in "$@"; do
    case $arg in
        --force) FORCE=true ;;
        --print-password) PRINT=true ;;
        --help)
            echo "Usage: generate_credentials <name> [--force] [--print-password]"
            exit 0
            ;;
        *)
            NAME="$arg"
            ;;
    esac
done

if [[ -z "$NAME" ]]; then
    echo "? Kein Name angegeben"
    echo "? Usage: generate_credentials <name>"
    exit 1
fi

WP_DIR="$HOME/www/$NAME"
ENV_FILE="$WP_DIR/.env"

mkdir -p "$WP_DIR"

echo "? Generiere Credentials f�r: $NAME"

if [[ -f "$ENV_FILE" && "$FORCE" = false ]]; then
    echo "??  .env existiert bereits"
    echo "? Nutze --force zum �berschreiben"
    exit 1
fi

# Passwort generieren
generate_password() {
    while true; do
        pw=$(tr -dc 'A-Za-z0-9!@#$%^*()_+=' < /dev/urandom | head -c 20)

        if [[ "$pw" =~ [A-Z] ]] &&
           [[ "$pw" =~ [a-z] ]] &&
           [[ "$pw" =~ [0-9] ]] &&
           [[ "$pw" =~ [^A-Za-z0-9] ]]; then
            echo "$pw"
            return
        fi
    done
}

DB_PASSWORD=$(generate_password)

# Datei schreiben (�berschreibt bewusst)
cat > "$ENV_FILE" <<EOF
DB_NAME='$NAME'
DB_USER='$NAME'
DB_PASSWORD='$DB_PASSWORD'
EOF

chmod 600 "$ENV_FILE"

echo "? .env erstellt"
echo "? Benutzer: $NAME"

if [[ "$PRINT" = true ]]; then
    echo "? Passwort: $DB_PASSWORD"
else
    echo "? Passwort: *********"
fi

🧠 Was ich dabei gelernt habe

1. Regex in Bash ist… speziell

Ich wollte ursprünglich explizit Sonderzeichen prüfen:

[!@#$%^&*()_+=]

👉 führt zu Syntaxfehlern (&!)

Die bessere Lösung:

[^A-Za-z0-9]

👉 „alles außer Buchstaben und Zahlen“

2. .env nicht einfach erweitern

Ein klassischer Fehler:

DB_PASSWORD=abc
DB_PASSWORD=xyz
DB_PASSWORD=123

👉 passiert schnell, wenn man >> statt > nutzt

Deshalb:

cat > file

👉 bewusst überschreiben

3. set -euo pipefail verstehen

Das ist kein magischer Copy-Paste, sondern extrem sinnvoll:

• -e → stoppt bei Fehlern
• -u → verhindert nicht gesetzte Variablen
• pipefail → erkennt Fehler in Pipes

👉 macht Bash-Skripte deutlich robuster

4. Idempotenz ist wichtiger als man denkt

Mein Skript bricht ab, wenn .env existiert:

--force

👉 bewusstes Überschreiben statt Chaos

🔗 Integration in andere Skripte

Die .env kann einfach geladen werden:

source .env

Und dann z. B.:

wp config create \
  --dbname="$DB_NAME" \
  --dbuser="$DB_USER" \
  --dbpass="$DB_PASSWORD"

🚀 Fazit

Mit einem kleinen Skript habe ich:

• konsistente Credentials
• weniger Fehler
• reproduzierbare Setups

Und vor allem:

👉 ein Problem gelöst, das extrem schwer zu debuggen war