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.

Plugins, Provider, PowerShell

Im Icinga-Windows-Kosmos passiert in letzter Zeit sehr viel, vor allem durch das Zauberwort PowerShell. Framework, Plugins, Kickstart und Service, das alles hört man recht oft und auch neue Releases sind da oder stehen an. Doch wie schreibe ich meine eigenen Checks beziehungsweise Plugins? Gibt es Vorschriften an die ich mich halten sollte? Und kann ich mich auch an dem Projekt beteiligen?

Plugins und Provider

Als das Projekt gestartet worden ist, war es bereits angedacht, dass Plugins individuell anpassbar sein sollten. Um dies zu gewährleisten, war es wichtig die Daten, die zur Prüfung genutzt werden in einer normierten Form gesammelt zurückzugeben und hier kommen die Provider ins Spiel.

Was ist ein Provider?

Ein Provider sammelt Daten vom System und stellt sie zur Verfügung um in Plugins genutzt zu werden. Sehen wir uns das ganze im icinga-powershell-plugins repository an:
└── provider
├── bios
├── cpu
├── directory
├── disks
├── enums
├── eventlog
├── memory
├── process
├── services
├── updates
├── users
└── windows

Innerhalb dieser Verzeichnisse befinden sich in der Regel zwei Dateien. Im Falle von CPU wären das Icinga_ProviderCpu.psm1 und Show-IcingaCpuData.psm1. Respektive Dateien existieren auch in allen anderen Verzeichnissen.

Mit dem gleichnamigen Befehl Show-IcingaCpuData kann man nun alle generischen Daten zur Thematik CPU abfragen. Während die Datei Icinga_ProviderCpu.psm1 verschiedene Funktionen enthält um spezifische Daten anzufordern. Darunter zum Beispiel folgende Funktionen: Get-IcingaCPUArchitecture, Get-IcingaCPUArchitecture.

Im Falle von Get-IcingaCPUs könnte der Output beziehungsweise die bezogenen Daten, wie folgt aussehen – gekürzt und in JSON konvertiert:
{
"specs":  {
"L3CacheSize":  0,
"CurrentClockSpeed":  2100,
"VoltageCaps":  0,
"L2CacheSpeed":  null,
"ThreadCount":  1,
"CurrentVoltage":  null,
"LoadPercentage":  7,
"L2CacheSize":  null
},
"errors":  {
"ErrorDescription":  null,
"ErrorCleared":  null,
"ConfigManagerErrorCode":  {
"value":  "This device is working properly.",
"raw":  0
},
"LastErrorCode":  null
},
"metadata":  {
"ProcessorType":  {
"value":  "Central Processor",
"raw":  3
},
...
"SocketDesignation":  "CPU 1",
"ProcessorID":  "078BFBFF000306A9",
"NumberOfCores":  1,
"SerialNumber":  "",
"Architecture":  {
"value":  "x64",
"raw":  9
},
"Availability":  {

},
"AddressWidth":  64,
"Status":  "OK",
"StatusInfo":  {
"value":  "Enabled",
"raw":  3
},

}

Auf diese Daten können wir nun Aufbauen. Ob die Daten direkt zuträglich sind oder ausreichend für unsere Anwendung ist individuell.

Bevor ich ein Plugin schreibe!

Bevor es dazu kommt, dass man ein Plugin schreibt und Unmengen an Cmdlets benutzt und die Daten normiert, sollte man sich darüber im Klaren sein, was es alles für Provider gibt und vorher überprüfen, ob die Daten nicht in der ein oder anderen Form bereits vorhanden sind.

Gefällt mir etwas am Invoke-IcingaCheckCPUs Check nicht, dann ist es sinnig, zumindest zunächst den Provider des Check-Plugins zu betrachten und zu prüfen ob man nicht die Informationen die der Check erhält anders nutzen kann.

Falls das nicht der Fall ist, sollte man seinen eigenen Provider schreiben oder einen vorhanden ergänzen und uns vielleicht mit einen Pull-Request überraschen.

Aber wohin das Ganze?

Damit nicht alles verloren ist beim nächsten Update oder Konflikte auftreten, gibt es im Icinga-PowerShell-Framework ein Custom-Verzeichnis. Dieses unterteilt sich wiederum in /lib und /plugins. In das plugins-Verzeichnis kommen folgerichtig natürlich die Plugins, die ihr für euch individuell anlegt und die nicht oder noch nicht Teil des Repositorys sind.

Das Gleiche gilt natürlich auf für das Library-Verzeichnis. Wenn ihr das Rad neu erfinden wollt und ein Custom-Module baut für Test-Numeric oder euch das Ausgabeformat von Convert-Bytes stört, dann sind eure Tools hier sicher. Und natürlich auch da freuen wir uns über einen Pull-Request.

Wir halten fest, wenn man also ein Plugin baut, dann sollte man ein eigenes PowerShell Modul bauen und sich dabei weitestgehend zunächst an den vorhandenen Plugins orientieren und aufpassen, wo was hingehört.

Fazit

Wer es richtig machen will, fängt langsam an und baut vor allem modular. Erst der Provider, dann das eigentliche Check-Plugin. Desto größer der Provider, desto einfacher das Bauen der Check-Plugins, weil mit bereits vorhanden Informationen ist die Logik, der Check-Prüfung das wenigste Problem.

Wem das alles noch nicht genug ist, der kann auch mal auf unserem Youtube-Channel vorbei schauen, wo wir im Umfang unserer Webinare mit unter Custom Plugin Development und Custom Daemon Development besprochen haben.

Seit in jeden Fall gespannt wie es mit dem Projekt weitergeht und für noch mehr zum Thema Plugin schreiben schaut euch den Developer-Guide an.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

Ansible – Use Blocks and Rescue Errors

Ansible is a widely used and powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

Since version 2.0.0 Ansible introduced the usage of blocks, they provide the possibility to group or rescue failed tasks.
On blocks we can assign most directives which are available for any other task at block level, only loops aren’t available.

- name: Update Systems
  hosts: all
  tasks:
    - name: execute this block only for rhel family hosts
      block:
        - name: install epel repository
          yum:
            name: epel-release
            state: present

        - name: install updates
          yum:
            name: '*'
            state: latest
            exclude: kernel*

      when: ansible_os_family == 'RedHat'
      become: true

When we try to deploy applications, sometimes we need to test connections or if requirements are met. When those tasks fail caused by the negative test result, the playbook by default fails and therefore stops.
To force Ansible to execute all other tasks, we could use the directive ignore_failed: true and checking the return value for any other depending task.

With blocks this is easily solved, by using rescue to catch the error and force a particular tasks to run.
The always will make sure that the listed tasks get executed.


- name: rescue my errors
  hosts: localhost
  tasks:
    - name: Try to reach host
      block:
        - name: "[Try reach DNS] Check Connection over DNS"
          command: ping client01.demo.local -c 2
          register: output
      rescue:
        - name: "[Rescue failed DNS] Check Connection over IP"
          command: ping 192.168.33.1 -c 2
          register: output
      always:
        - debug:
            var: output

To handle more than one rescue statement, the block can be simply used in the rescue section, like in the following example.


  - name: Try to execute skript
    block:
      - name: Check Connection over DNS
        command: ping nclient01.demo.local -c 2
        register: output
    rescue:
      - name: "this will fail"
        block:
          - name: it will be false
            command: /bin/false
            register: output
        rescue:
          - name: "this works"
            command: ping 192.168.33.1 -c 2
            register: output

Try to reduce ignored tasks in failed state with rescue blocks, this reduces the confusion of users when inspecting the output.
As second advice try to reduce code duplication by grouping tasks with similar directives.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Überspringen von Online-Werbung in Videos mit dem Mac

Ich nutze seit vielen Jahren Magnet auf dem Mac um verschiedene Fenster schnell zu positionieren. Was bei vielen anderen Betriebssystemen einfach geht, kann man mit Magnet Add-on einfach nachrüsten. Bei der Neuinstallation von Magnet bin ich auf eine andere App der gleichen Entwickler mit dem Namen Dynamo gestossen.

Aufgrund der guten Rezessionen habe ich die 99 Cent investiert und bin begeistert. Dynamo ist eine Safari Extension, welche nach Installation ein paar Keyboard-Controls (diese können auch geändert werden) zur Verfügung stellt.

Mit den Tasten S, D und F kann die Geschwindigkeit des Videos verlangsamt (S), beschleunigt (F) und wieder auf normal (D) gesetzt werden. Das ist Hilfreich, wenn man bei längeren Videos an die richtige Stelle hüpfen möchte ohne sich ständig beim Quick-Scrolling zu verklicken.

Für mich ist das Killerfeature jedoch die Taste E, mit welcher die Werbung in Videos einfach übersprungen werden kann. Ein Tastendruck genügt und das eigentliche Video beginnt. Dynamo funktioniert nicht nur auf YouTube, sondern auf sämtlichen anderen Website mit Videoplayer. Auch Videos auf Spiegel.de, dessen Werbeanzeigen sich normalerweise nicht überspringen lassen und auch pausiert werden, sobald das Fenster im Hintergrund ist, können problems ohne Werbung betrachtet werden.

Kurzum, wenn ihr Safari verwendet und öfters mal Videos anschaut sind die 99 Cent eine bombastische Investition.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und...

Die Out of the Box Experience

Hallo!

Ich würde gern ein aktuelles Thema aufgreifen, das in letzter Zeit viele Leute beschäftigt. Da aus aktuellem Anlass viele Leute ins Homeoffice gehen mussten und nun von dort ihre Arbeit verrichten, haben viele neue Monitore, Rechner, Mikros und Software erhalten, um dies zu bewältigen.

Nun gibt es aber die schon oben beschriebene Erfahrung, die aus rein subjektiver Sicht entscheidet, ob man mit dem neuen Produkt zufrieden ist oder es gleich wieder einpacken und zurückschicken will.

Das Feld ‘Videokonferenzen’ will ich hier gar nicht betreten. Da hat jeder andere Präferenzen.

Mir geht es in dem Blogpost eher um die “Experience”, ein tolles Marketing-Buzzword, bei dem sich am liebsten jeder unter der Couch verstecken möchte. Die Erfahrung, die man mit dem jeweiligen Produkt direkt nach dem Auspacken macht, ist sehr variabel.

Nehmen wir mal als Beispiel einen neuen Firmenlaptop. Wir haben ihn aus der Verpackung gepult und drücken auf den Powerknopf und unsere neue Kiste mit SSD und mehr Speicher & CPU Kraft aller Großrechner in den 80zigern dümpelt 5 Minuten in einem Regenbogenfarbenen Waiting Screen von Windows umher in dem uns mitgeteilt wird das wir uns freuen dürfen das ‘now’ etwas für uns passiert.

NOT!!!! Jemanden warten zu lassen ist keine ‘Gute’ Out of the Box Erfahrung. Auch 4-5 Sicherheitsfragen welche sowas lustiges wissen wollen wie “Was war ihr erstes Haustier” … sind eher Anti Security .. Rein statistisch hat man hier schon in den USA mit sowas wie ‘Spot’ einen Treffer um in einen Benutzeraccount rein zu kommen.

Idealerweise sollte man nicht warten müssen . NEVER make your Customer wait.

Das wussten selbst Betriebssysteme aus der prähistorischen Ära. Einschalten, Loslegen. C64 => Einschalten und READY.
Selbst die Amiga Workbench war nach dem Starten direkt verfügbar und auch Atari TOS auf dem ST. Nun sind wir im Jahr 2020 AD.

Aus Sicht eines Endbenutzers ist das keine gute Erfahrung (Warten, abgreifen personenbezogener Daten für Marketing-Zwecke, Sicherheitsexploit-Fragen) und zum goldenen Abschluss, nachdem man die ganze Prozedur hinter sich hat, kommt noch ein haufen Autoupdates, die noch installiert werden müssen, bevor man effektiv anfangen kann zu arbeiten.

Selbst bei Konsolen ist die Out of the Box Erfahrung … inzwischen hundsmiserabel.
Früher: SNES Spiel in die Konsole stecken und läuft. Heute: Mindestens 2 Anmeldungen. Einmal Hersteller spezifisch XBox Account/STEAM Account/PSX Account und dann gegebenenfalls nochmal die des Spieleherstellers und dessen Plattform inkl. Werbung.

Das künstliche Gold der Marketing/Wertschöpfungskette von Daten, die nur um deren Selbstwillen für User Tracking generiert werden, ist bis in das einfachste Produkt vorgedrungen. Selbst meine Bose Wireless Kopfhörer wollen meinen Alex Account Zugriff um mir ‘Mehr Info’ liefern zu können.

Da ich nun sehr abgedriftet bin von der Thematik: Die “Auspack und sofort Loslegen Erfahrung” ist sehr “Simplismus” geprägt, man findet die “Out of the Box” Erfahrung am idealsten, wenn man direkt loslegen kann.
Kein wenn und kein aber.
Zu einem späteren Zeitpunkt können die Settings des Produktes verfeinert werden. Also ggf. einen Account anlegen, höhere Security Settings setzen und andere Einstellungen vornehmen.

Aber die Defaults sollten IMMER zu einem produktiven Ergebnis führen.

Software ist auch ein Werkzeug wie ein Schraubenzieher. Der will auch nicht, dass ich bei ‘Binford’ einen Account anlege. bevor ich die erste Schraube in das Holzbrett drehe. Software & Betriebssysteme sollten allgemein wieder auf Funktionalität ausgelegt werden anstelle von Subscription ‘featureitis’ …

Das baut nur unnötige Hürden und Fehlerquellen auf und dient nur dem Selbstzweck.
Einstecken, Einschalten & Loslegen war mal die Devise – ich hoffe, dass nach all den bitteren Erfahrungen der letzten Zeit wieder auf diese Out of the Box Erfahrung Wert gelegt wird.

In dem Sinne ‘Good Luck and Good Night’

Bis zum nächsten Mal

David

Das Nette Katzenfoto wurde bereitgestellt von

Photo by DNK.PHOTO on Unsplash.

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Aufsetzen eines Redis-clusters

Da mir vor kurzem die Aufgabe zuteil wurde, einen Redis Cluster aufzusetzen, möchte ich diese Erfahrung mit euch teilen.
Die Vorbereitung:
 3 Nodes
– Redis in der aktuellen stabilen Version

Auf allen 3 Nodes die aktuelle (stable) Redis Version herunterladen und das tar.gz file entpacken
wget http://download.redis.io/releases/redis-stable-version.tar.gz
tar -xvzf redis-stable-version.tar.gz -C /opt/
cd /opt/redis-stable-version/
make

Da der Cluster aus 6 Nodes bestehen muss (minimal), laufen auf jedem Node ein Master-Prozess und ein Slave-Prozess, deshalb sollte man ein Verzeichnis Cluster anlegen in dem dann eine master.conf und slave.conf liegt, die unterschiedlich konfiguriert sind.
zum Beispiel:
master.conf Node 1:
port 7000
logfile /var/log/redis/redis-master.log
bind 192.168.33.50
cluster-enabled yes
cluster-config-file nodes-master.conf
cluster-node-timeout 5000
appendonly yes
----
slave.conf Node 1:
port 7001
logfile /var/log/redis/redis-slave.log
bind 192.168.33.50
cluster-enabled yes
cluster-config-file nodes-slave.conf
cluster-node-timeout 5000
appendonly yes

Zur Erklärung: Ich habe jetzt den Master-Prozess Ports immer auf eine gerade Zahl gelegt (7000, 7002, 7004)
und die Slaves auf (7001, 7003, 7005). Die bind IP-Adresse ist auch wichtig auf dem jeweiligen Node zu binden.
Die Angabe von der nodes-master.conf / nodes-slave.conf ist dafür, damit hier der Status der Master/Slave Nodes hinein geschrieben werden
und diese Dateien werden beim Start automatisch erstellt.

z.B Node 3:
~# cat /opt/redis-5.0.7/cluster/master.conf
port 7004
logfile /var/log/redis/redis-master.log
bind 192.168.33.52
cluster-enabled yes
cluster-config-file nodes-master.conf
cluster-node-timeout 5000
appendonly yes

Die Nodes werden alle 3 so mit Konfigurationsdateien erstellt damit später der Cluster gebaut werden kann.

Starten der Prozesse auf den drei Nodes:
cd /opt/redis-stable-version/cluster && ../src/redis-server ./master.conf &
../src/redis-server ./slave.conf &
pgrep -a redis-server
# pgrep -fl redis-server
1988 redis-server
1992 redis-server

Bevor wir den Cluster zusammenhängen sollte man auf jedem Node prüfen, ob beide redis-server Prozesse laufen, siehe pgrep Kommando.

Cluster zusammenhängen:
Auf dem ersten Master-Node wird das redis-cli Kommando ausgeführt:
~# redis-cli --cluster create 192.168.33.50:7000 192.168.33.50:7001 192.168.33.51:7002 192.168.33.51:7003 192.168.33.52:7004 192.168.33.52:7005 --cluster-replicas 1
Wie man am Kommando erkennen kann, werden hier alle Master / Slave-Nodes mit ihrem Port zum einem Cluster verbunden –cluster-replicas 1 bedeutet, das zu jedem Master Node ein Slave konfiguriert ist.
Man muss die erstellte Konfiguration noch mit “yes” bestätigen und anschließend sollte man folgenden Output erhalten:
[OK] All 16384 slots covered
Jetzt kann man per redis-cli mit dem Cluster kommunizieren, Werte setzen, Statis abfragen usw, in der Online-Dokumentation von Redis sind einige Bespiele vermerkt.
So, hat man einen lauffähigen Redis-Cluster am Start, es besteht auch ein fertiges Bash-Skript womit man einen fertigen Redis-Cluster auf einem Node starten kann, dieses ist unter dem Verzeichnis ‘/redis-stable-version/utils/’ zu finden und als Schnelltest verwendet werden kann.

Das soll es fürs erste mal reichen und ich wünsch euch viel Spaß mit eurem ersten Redis Cluster. Natürlich möchte ich auch hier wieder auf unser Trainingsangebot im OpenSource aufmerksam machen, ihr wisst “Training = “Wissen”, immer fleißig weiterbilden 🙂

Johannes Carraro
Johannes Carraro
Support Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.