MySQL – Show open connections and processes

Einmal an die eigene Notizwand gekritzelt:

  1. MySQL Verbindungen + weitere Verbindungsrelevante Infos anzeigen:
    root@localhost [(none)]> show status like '%onn%';
    +--------------------------+--------+
    | Variable_name            | Value  |
    +--------------------------+--------+
    | Aborted_connects         | 0      |
    | Connections              | 440921 |
    | Max_used_connections     | 67     |
    | Ssl_client_connects      | 0      |
    | Ssl_connect_renegotiates | 0      |
    | Ssl_finished_connects    | 0      |
    | Threads_connected        | 2      |
    +--------------------------+--------+
    7 rows in set (0.00 sec)
  2. MySQL Prozessliste anzeigen:
    root@localhost [(none)]> show processlist;
    +--------+-------+-----------+-------+---------+------+-------+------------------+
    | Id     | User  | Host      | db    | Command | Time | State | Info             |
    +--------+-------+-----------+-------+---------+------+-------+------------------+
    | 440912 | ttrss | localhost | ttrss | Sleep   |    0 |       | NULL             |
    | 440919 | root  | localhost | NULL  | Query   |    0 | NULL  | show processlist |
    +--------+-------+-----------+-------+---------+------+-------+------------------+
    2 rows in set (0.00 sec)
  3. Der status Parameter der mysqladmin Binary auf der Kommandozeile:
    root@host ~ $ mysqladmin status
    Uptime: 1621495  Threads: 2  Questions: 18982236  Slow queries: 6  Opens: 83474  Flush tables: 1  Open tables: 400  Queries per second avg: 11.706
    
  4. Und last but not least auch noch einmal die Prompt-Einstellung aus der /etc/mysql/my.cnf festgehalten:
    [mysql]
    prompt = \u@\h [\d]>\_

Die MySQL Befehle habe ich von dieser Webseite kopiert. Die Prompt Einstellungen weiß ich nicht mehr woher…

Let’s Encrypt und Puppet

lets-encrypt-logoIch habe früher fast alle meine Zertifikate von CAcert bezogen. Ich habe sie regelmäßig aktualisiert und für das deployen habe ich ein Puppet Modul, dass die Zertifikate verteilt.

Nach und nach bin ich auf Let’s Encrypt Zertifikate umgestiegen. Da ein hoher Grad an Automatisierung bei Let’s Encrypt immer wieder propagiert wird dachte ich mir, dass sollte auch mit Puppet dann kein zu großes Problem sein. Hier die Lösung, die bei mir nun in Betrieb ist:

Als erstes habe ich das Puppet Modul bzed/letsencrypt installiert. Das Modul benötigt eine PuppetDB. Über exported resources  transportiert es die CSRs auf den puppetmaster, macht dort die gesamte Abwicklung und transferiert dann die Ergebnisse wieder zurück auf den Node. Das funktioniert auch sehr gut.

Auf dem Puppetmaster habe ich die Klasse eingebunden und einige wenige Einstellungen gesetzt (hiera). Bei dem Hook handelt sich m übrigen um einen letsencrypt.sh Hook:

---
classes:
  - letsencrypt

letsencrypt::challengetype: 'http-01'
letsencrypt::hook_source: 'puppet:///modules/helper/%{::fqdn}/le_hook.sh'

Auf den Nodes habe ich die Klasse eingebunden und die Domains definiert für die ein Zertifikat bezogen werden soll:

---
classes:
- letsencrypt

letsencrypt::domains:
- 'foo.example.net'
- 'bar.example.net'
- 'baz.example.net'

PL_logo_vertical_RGB_lgIn meinem recht simplen Szenario ist es so, dass ich einen Gate-Server habe, hinter dem sich alle anderen Maschinen „verstecken“. Dort läuft ein Apache Server als Proxy, der Anfragen über HTTP nach hinten weiterreicht. Die Konfiguration von Apache erfolgt ebenfalls über Puppet. Eine Authentifizierung über DNS für ACME klappt bei mir leider nicht, weswegen ich HTTP nehmen muss. Das habe ich so gelöst, dass ich für die Apache vhosts einfach über ProxyPassMatch den .well-known/acme-challenge/ auf einen Apache Vhost auf dem Puppetmaster weiterreiche. Auf dem Gate-Server sieht das für einen Vhost wie folgt aus:

apache::vhost:
  'proxy-foo.example.net':
    servername: 'foo.example.net'
    serveradmin: 'webmaster@example.net'
    port: '80'
    docroot: '/var/www/empty'
    proxy_dest: 'http://10.20.30.1'
    proxy_pass_match:
      -
        path: '^/.well-known/acme-challenge/(.*)$'
        url: 'http://10.20.30.2/$1'
        params:
          retry: '0'
    headers:
      - 'unset X-Powered-By'
    proxy_preserve_host: true

Auf dem Puppetmaster wiederum läuft ein Vhost, der einfach alle Domains als ServerAlias eingetragen hat.

Nun kommt noch der Hook für letsencrypt.sh ins Spiel den ich oben bereits erwähnt habe. Das Skript schreibt die ACME-Challenge in eine Textdatei in den DocRoot und löscht sie nach dem Erfolg wieder:

#!/bin/bash
 
#
# http-01 hook
#
 
CHALLENGEDIR="/var/www/example.net/letsencrypt"
 
done="no"
if [[ "$1" = "deploy_challenge" ]]; then
    echo "${4}" > "${CHALLENGEDIR}/${3}"
    chmod 644 "${CHALLENGEDIR}/${3}"
    done="yes"
fi
 
if [[ "$1" = "clean_challenge" ]]; then
    rm "${CHALLENGEDIR}/${3}"
    done="yes"
fi
 
if [[ "${1}" = "deploy_cert" ]]; then
    # do nothing for now
    done="yes"
fi
 
if [[ ! "${done}" = "yes" ]]; then
    echo Unkown hook "${1}"
    exit 1
fi
 
exit 0

Voila! Es braucht ein paar Durchläufe bis alles über die Puppetdb jeweils transportiert wurde, aber alles läuft vollautomatisch ab. Sehr cool!

Projekt: pregos files

Vor ein paar Jahren hab ich mal file delivery implementiert, dann aber nie weiter verfolgt. Jetzt habe ich das ganze noch einmal deutlich einfacher geskriptet.

pregos files

Die Features sind:

  • Dateiuploads laufen nach einer Zeitperiode ab
  • Downloadnamen werden automatisch generiert um nicht einfach geraten zu werden
  • Optional kann ein eigener, sprechender Downloadname angegeben werden
  • Optional können Downloads mit einem Passwort gesichert werden
  • Emailbenachrichtigung bei Download
  • Emailbenachrichtigung wenn eine Datei bald abläuft
  • Benutzerauthentifizierung für Dateiupload
  • Standard- und Admin Benutzerrollen
  • Adminbenutzer können andere Benutzer verwalten und sehen eine Liste aller verfügbarer Dateien

Den Quelltext gibt es auf Github.