Alle User in MySQL anzeigen

Oftmals wachsen Datenbankinstallationen im Laufe der Zeit und man legt immer wieder für neue Projekte neue Datenbanknutzer an. Um hier den Überblick zu behalten, zeige ich kurz, wie man sich die jeweiligen Nutzer anzeigen lassen kann.

Voraussetzungen:

  • Command line/Terminal
  • MySQL oder MariaDB installiert
  • Benutzer in MySQL:Benutzer mit Sudo- oder Root-Rechten

Bei der Installation von MySQL wird bei der Installation als erster Benutzer der Root-Benutzer erstellt – der MYSQL-Administrator. Der Root-Benutzer ist berechtigt, alles in der MySQL-Datenbank zu tun – Eine einfache und zuverlässige Möglichkeit, die MySQL-Sicherheit zu erhöhen, besteht darin, Benutzer mit eingeschränkten Berechtigungsbeschränkungen für die Datenbank zu erstellen.

Wenn Sie Zugriff auf Ihren Server haben, müssen Sie die MySQL-Konsole aufrufen. Dafür benötigen wir Root-Rechte. Geben Sie dies in die Befehlszeile ein:

sudo mysql -u root -p

root@galeria-1:~# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 78
Server version: 10.4.13-MariaDB-1:10.4.13+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Dann müssen Sie Ihr MySQL-Root-Passwort eingeben. Es sollte sich vom System-Root-Passwort unterscheiden. Sobald Sie in der MySQL-Konsole root sind, können Sie Abfragen und Befehle ausführen. MySQL-Benutzer anzeigen: Jetzt können Sie alle Benutzer in MySQL mit dem folgenden MySQL-Befehl auflisten:

MariaDB [(none)]> SELECT user FROM mysql.user;
+-------------+
| User |
+-------------+
| mariadb.sys |
| mysql |
| root |
| testuser | 
+-------------+
4 rows in set (0.004 sec)
MariaDB [(none)]>
Moumen Amneh
Moumen Amneh
Junior Systems Engineer

Mou startete seine Ausbildung zum Fachinformatiker Systemintegration im September 2019 bei uns. Mit vollem Ehrgeiz widmet er sich jetzt Puppet, Icinga und Co. und lernt jeden Tag neues dazu. Neben der Arbeit brilliert er auf dem Fussballplatz und das zum verwechseln ähnlich mit seinem Namensvetter bei Liverpool.

Monitor das Monitoring_by_ssh

Quelle: https://medium.com/

Hellow,

heute möchte ich euch zeigen, wie man schnell und einfach mit Icinga 2 seine bestehende Icinga 2 Infrastruktur monitoren kann.

Jeder der sich damit schon mal befasst hat, wird schnell zu dem Ergebnis kommen: “Hey warte mal den Master kann ich ja nicht auf den anderen Master drauf packen.”, falls nicht, ist das die Tatsache. Zitat “Henne-Ei-Problem”.

Die Lösung dieses Problems ist allerding recht simpel. Nachdem wir den jeweiligen Icinga 2 Core nicht heranziehen können, machen wir ganz einfach gebrauch von check_by_ssh. Somit können wir völlig unabhängig der Icinga 2 Infrastruktur entlang unsere Monitoring Instanzen monitoren.

Hierfür verwende ich zwei Vagrant Boxen die aus einer aktuellen CentOS 7 und Icinga 2 Installation besteht. Box #1 ist der Icinga 2 Core und Box #2 der “Monitor the Monitoring”.

Auf der Box #1 muss zunächst ein Benutzer angelegt werden:

# Benutzer icinga hinzufügen
useradd -m icinga

# Temporäres Kennwort vergeben
passwd icinga

Auf der Box #2 müssen vorbereitend folgende Schritte ausgeführt werden:

# Shell für den icinga Benutzer aktivieren:
usermod --shell /bin/bash icinga

# SSH-Key für den icinga Benutzer erzeugen.
ssh-keygen -b 4096 -t rsa -C "icinga@$(hostname) user for check_by_ssh" -f $HOME/.ssh/id_rsa

# SSH-Key auf die Box #1 kopieren
ssh-copy-id -i $HOME/.ssh/id_rsa icinga@master1.int.mbp.local

# Anschließend prüfen ob das ganze geklappt hat
ssh -i $HOME/.ssh/id_rsa icinga@master1.int.mbp.local

Nun haben wir sämtliche Vorbereitungen abgeschlossen, nur noch eben aufräumen:

# Auf der Box #1 wird die Passwortanmeldung des icinga Benutzers deaktiviert
passwd -l icinga
# Auf der Box #2 wird die Shell des icinga Benutzers wieder in den Default Zustand gebracht
usermod -s /sbin/nologin icinga

Das Ziel liegt nun nicht mehr all zu fern, wir begeben uns auf Box #2 und erzeugen Icinga 2 Konfiguration:

# Man legt zwei Verzeichnisse unter "/etc/icinga2/zones.d" an
mkdir -pv /etc/icinga2/zones.d/{global-templates,master}

# Wechseln in das "global-templates" Verzeichnis und kopieren von Github die Check-Commands für check_by_ssh
cd /etc/icinga2/zones.d/global-templates
wget https://raw.githubusercontent.com/lbetz/icinga-commands/master/commands-ssh.conf

# Nun wechseln wir in das "master" Verzeichnis und legen dort ein Konfiguration für die Box #1 an
cd /etc/icinga2/zones.d/master
touch master1.int.mbp.local.conf

# Folgende Konfiguration enthält das Host Objekt "master1"

object Host "master1.int.mbp.local" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "hostalive"

    display_name = "master1"
    address = "127.28.128.11"
}

object Service "LIN load" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_load"

    host_name = "master1.int.mbp.local"
}

object Service "LIN disk" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_disk"

    host_name = "master1.int.mbp.local"
}

object Service "LIN swap" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_swap"

    host_name = "master1.int.mbp.local"
}

object Service "LIN time" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_ntp_time"

    host_name = "master1.int.mbp.local"
}

object Service "LIN proc icinga" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_procs"

    host_name = "master1.int.mbp.local"

    vars.by_ssh_arguments = {
        "-u" = "$procs_user$"
        "-w" = "$procs_warning$"
        "-c" = "$procs_critical$"
    }
    vars.procs_user = "icinga"
    vars.procs_warning = "250"
    vars.procs_critical = "0:300"
}

object Service "LIN proc mysql" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "by_ssh_procs"

    host_name = "master1.int.mbp.local"

    vars.by_ssh_arguments = {
        "-u" = "$procs_user$"
        "-c" = "$procs_critical$"
    }
    vars.procs_user = "mysql"
    vars.procs_critical = "0:1"
}

object Service "LIN port 5665" {
    check_interval = 300
    retry_interval = 60
    max_check_attempts = 3

    check_command = "tcp"

    host_name = "master1.int.mbp.local"

    vars.tcp_port = "5665"
}

# Anschließend Konfiguration Prüfen und den Icinga 2 Core neustarten
icinga2 daemon -C
systemctl restart icinga2

Nun dauert es einen Moment und dann sollten sämtliche Werte und Dienste des Icinga 2 Masters überwacht werden.

Damit verabschiede ich mich auch schon wieder und wünsche wie immer Spass beim basteln!

P.S.: Wem das noch nicht genüge sollte, dem kann ich noch das check_mysql_health in Kombination mit der Icinga 2 IDO auf dem Weg geben.

rsync und was dann?

Diese Woche hatte ich die zweifelhafte Ehre die mit 1,6TB schon etwas größere MySQL-Datenbank (MariaDB) eines Kunden auf den zweiten Datenbankknoten zu spielen. Dabei war die Herausforderung das die ganze Show außerhalb der Geschäftszeiten von 17:30 Uhr bis max. 5:00 Uhr stattfindet. Ein Dump der Datenbank dauert erfahrungsgemäß zu lange um das Wartungsfenster einzuhalten. Kein Problem dachte ich mir, dann halt rsync auf Dateiebene. Also die Datenbankzugriffe pünktlich zu Beginn des Wartungsfensters unterbunden, die Datenbank gestoppt und den rsync vom Zielsystem aus wie folgt gestartet:

# rsync -avPz --exclude 'ib_logfile*' root@a.b.c.d:/var/lib/mysql/ /var/lib/mysql/

Eine kurze Erklärung der gesetzten Parameter:

  • a – kopiert rekursiv unter Beibehaltung der Dateiberechtigungen
  • v – sorgt für eine ausführlichere Ausgabe (verbose)
  • P – zeigt eine Fortschrittsanzeige (progress) und setzt den Transfer bei einem evtl. Abbruch fort (partial)
  • z – aktiviert die Komprimierung, meistens bei einer Übertragung via Netzwerk sinnvoll

Die beiden InnoDB Logfiles (ib_logfile0 und ib_logfile1) mit jeweils 11GB wurden für eine schnellere Übertragung ausgeschlossen, da sie beim Anstarten eh wieder neu erstellt werden.

Leider hat sich relativ schnell herausgestellt dass das nicht der Weisheit letzter Schluss war, da die Übertragung mit ca. 15MB/s an die 32 Stunden gedauert und damit das Wartungsfenster überschritten hätte. Auch eine Anpassung der Parameter und der Synchronisationsvorgang auf ein schnelleres Storage mit max. 40MB/s und damit fast 15 Stunden wären zu lange gewesen.

Nach einer kurzen Internetrecherche bin ich auf eine mögliche Lösung mit mbuffer gestossen. Der “measuring buffer” steht bereits als kleines Paket für die gängigen Linux-Distributionen zur Verfügung und sorgt dafür das es durch einen Puffer nie zu einem Leerlauf des Datenstroms kommt und die Verbindung somit nicht abreißen kann. Mit Komprimierungsfunktionalität und etwas “Bash-Magic” außenrum kann das dann so aussehen:

# tar cf - * | mbuffer -m 1024M | ssh a.b.c.d '(cd /var/lib/mysql; tar xf -)'

Dem zuzusehen war schon fast eine Freude, hätte nur noch eine Tüte Chips und vielleicht ein passendes Kaltgetränk gefehlt. Mit Transferraten von bis zu 350MB/s hat der Kopiervorgang so gerade mal über 2 Stunden gedauert (Durchschnitt 216MB/s) und die Umgebung bis zum Ende des Wartungsfensters längst wieder im Normalzustand. Das in vielen Fällen schon hilfreiche rsync kommt v.a. bei sehr vielen oder sehr großen Dateien durch die Checksummenberechnung an seine Grenzen, sodass mbuffer hier durchaus mehr als nur eine Alternative sein kann.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 12: Profile Part IV

This entry is part 12 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute geht es mit der Konfiguration von Icinga Web 2 weiter, nach dem im letzte Teil als Voraussetzung PHP konfiguriert wurde. Als Backend zur Speicherung von Authentifizierungs- und Benutzerdaten, kommt eine eigene MySQL Datenbank auf dem gleichen lokalen System zum Einsatz. Der Datenbank- und der Benutzername, sowie dass Passwort soll mittels Parameter festgelegt werden könnten, das gleiche gilt für den zum Senden von Kommandos an Icinga benötigten API-Benutzer und man soll sich als Webserver zwischen einem Apache bzw. einem Nginx entscheiden können. Die Konfiguration letztgenannter, wird im nächsten Teil der kommenden Woche behandelt.

class profile::icinga2::server(
  String                    $web_db_pass,
  String                    $web_api_pass,
  ...
  String                    $web_db_user  = 'icingaweb2',
  String                    $web_db_name  = 'icingaweb2',
  String                    $web_api_user = 'icingaweb2',
  Enum['apache', 'nginx']   $web_server   = 'apache',
) {
  ...
  mysql::db { $web_db_name:
    host     => $web_db_host,
    user     => $web_db_user,
    password => $web_db_pass,
    grant    => ['ALL'],
    before   => Class['icingaweb2'],
  }
  if $web_server == 'nginx' {
    $manage_package = true
#    $web_conf_user =
  } else {
    $manage_package = false
#    $web_conf_user =
    package { 'icingaweb2':
      ensure => installed,
    }
  }
  class { 'icingaweb2':
    db_username    => $web_db_user,
    db_password    => $web_db_pass,
    import_schema  => true,
    config_backend => 'db',
    conf_user      => $web_conf_user,
    manage_package => $manage_package,
  }
  ::icinga2::object::apiuser { $web_api_user:
    ensure      => present,
    password    => $web_api_pass,
    permissions => [ 'status/query', 'actions/*', 'objects/modify/*', 'objects/query/*' ],
    target      => '/etc/icinga2/conf.d/api-users.conf',
  }
  class { '::icingaweb2::module::monitoring':
    ido_db_host       => '127.0.0.1',
    ido_db_name       => $ido_db_name,
    ido_db_username   => $ido_db_user,
    ido_db_password   => $ido_db_pass,
    commandtransports => {
      'icinga2' => {
        transport => 'api',
        username  => $web_api_user,
        password  => $web_api_pass,
      }
    }
  }
}
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II

This entry is part 10 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

In Weiterführung vom letzten Post dieser Serie, beschäftigen wir uns zuerst damit dem Icinga-Server eine CA hinzuzufügen. Dies erledigt die Deklaration der Klasse icinga2::pki::ca. Sie erzeugt auch noch gleich ein Zertifikat für den eigenen Server.
Das ist auch der Grund, warum im Folgenden der Parameter pki des Features API mit none belegt werden muss, da genau dies verhindert, dass nochmals versucht wird ein Zertifikat zu generieren. Dieser Wert für pki ist also nur sinnvoll für Hosts mit einer Icinga-2-CA.

class profile::icinga2::server {
  ...
  #
  # CA / API
  #
  include ::icinga2::pki::ca
  class { '::icinga2::feature::api':
    pki             => 'none',
    accept_commands => true,
  }

Als nächstes widmen wir uns dem Feature IDO, welches die IDO-DB befüllt, hier eine MySQL-Datenbank, die ebenfalls per Puppet verwaltet werden soll und sich auch dem gleichen Server befindet. Hierfür ist zusätzlich das MySQL-Puppetmodule erforderlich. Das Datenbank-Schema kann vom Icinga2-Modul automatisch angelegt werden. Hierfür ist dann zu den üblichen Berechtigungen auch CREATE für den Benutzer, den auch Icinga für den Zugriff verwendet, erforderlich, da auch dieser zum initalen Erzeugen der Tabellen vom Icinga2-Modul verwendet wird.
In Bezug auf die Reihenfolge der Abarbeitung unserer Ressourcen, muss nur dafür Sorge getragen werden, dass die Datenbank für die IDO vor dem IDO-Feature dran kommt.
Für den zu verwenden Benutzernamen, das zugehörige Passwort und den eigentlichen Datenbanknamen fügen wir der Profilklasse Parameter hinzu. Im Gegensatz zum Datenbank- und Benutzernamen, die beide als Default icinga2 gesetzt bekommen, ist das Passwort als Parameter vom Endbenutzer immer selbst anzugeben.

class profile::icinga2::server(
  String   $ido_db_pass,
  String   $ido_db_name  = 'icinga2',
  String   $ido_db_user  = 'icinga2',
) {
  case $::osfamily {
    'redhat': {
      ...
      package { [ 'nagios-plugins-all', 'icinga2', 'icinga2-ido-mysql' ]:
        ensure => installed,
        before => User['icinga'],
      }
      ...
    }
    ...
  }
  #
  # Icinga 2
  #
  class { '::icinga2':
    manage_package => $manage_package,
    manage_repo    => $manage_repo,
  }
  #
  # IDO database
  #
  include ::mysql::server
  mysql::db { $ido_db_name:
    user     => $ido_db_user,
    password => $ido_db_pass,
    host     => '127.0.0.1',
    grant    => ['SELECT', 'INSERT', 'UPDATE', 'DELETE', 'DROP', 'CREATE VIEW', 'CREATE', 'INDEX', 'EXECUTE', 'ALTER'],
    before   => Class['icinga2::feature::idomysql']
  }
  class{ '::icinga2::feature::idomysql':
    user          => $ido_db_user,
    password      => $ido_db_pass,
    database      => $ido_db_name,
    import_schema => true,
  }

Auf RedHat-Systemen musste, wie in vorherigen Teil zu sehen war, da Paketmanagement aus dem eigentlichen Icinga-Modul herausgezogen werden, um den Benutzer icinga zwischen Paketinstallation und Icinga-Klasse verwalten zu können. Das bezieht sich nun ebenfalls auf das Paket icinga2-ido-mysql, das für das IDO-Feature erforderlich ist. Debianbasierte Systeme sind hiervon nicht betroffen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

HAProxy und SQL Grants

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.