Select Page

NETWAYS Blog

Warum wir in den NETWAYS-PostgreSQL-Trainings eigentlich nur “psql” nutzen

by | Oct 8, 2020 | , , ,

Wieder einmal PostgreSQL Schlung (Fundamentals und Advanced) durchgeführt.
Wieder einmal wurde nach GUIs gefragt.
Wieder einmal haben wir uns dann letztlich doch fast auf psql beschränkt.

Warum ist das so?

 

GUI vs. TUI – the eternal battle

GUIs werden i. A. als “benutzerfreundlicher” dargestellt.

Ich persönlich wiederum finde es ganz schrecklich, dauernd zur Maus greifen zu müssen, um irgendeine Aktion auszulösen, für die die Entwickler keinen oder einen grauenhaften Shortcut konfiguriert haben… für mich sind GUIs also eher weniger benutzerfreundlich.

Mir ist auch klar, dass es beileibe nicht jedem Menschen so geht, und die Gewöhnung spielt dabei sicher auch eine enorme Rolle.

“The usual suspects”: die üblicherweise genannten Gründe pro GUI/TUI

GUI:

  • intuitiver zu bedienen
  • “gewohnte” Optik
  • bessere Übersicht über Ergebnisse von Queries

TUI:

  • steht vom Funktionsumfang dem GUI kaum nach
  • funktioniert auch bei langsamer Verbindung (“Zug”)
  • kann gescriptet werden

Es gibt aber einige durchaus schwerwiegende Gründe, warum ich bei Trainings so einen großen Wert auf psql lege.

“The killer arguments”: warum psql elementar ist

Die Lernschwelle ist bei GUIs unnötig hoch

  • Jedes GUI sieht letztlich (ein wenig) anders aus und es gibt einfach zu viele
  • Um eine erste Verbindung herzustellen, muss im GUI erst ein Server definiert werden, mit jeder Menge Parametern, u.a. einer Netzwerkverbindung
    • dafür muss aber erst ein Konfigurationsparameter (listen_addresses=) gesetzt werden, was wiederum erst deutlich nach dem ersten “Reinschnuppern” behandelt wird…
    • Im Terminal hingegen (wo ich ja gerade den DB-Server installiert habe) komme ich per psql direkt an die DB (wenn ich der OS-User postgres bin…)
  • Objekte anschauen (“Erste Schritte”):
    • TUI: nach Eingabe von psql kann ich einfach z.B. \dt eingeben und bekomme alle Tabellen gelistet, \d nachnamen zeigt mir instant die Tabellenstruktur, dazu Indexe, Primär-/Fremdschlüssel etc. an
    • in allen GUIs muss ich dafür erst durch einen Baum klicken, in pgAdmin4 z.B. Servergruppe -> Server -> Datenbank -> Schemas -> ‘public’ -> Tabellen

Die (online-)Trainings-VMs sind nur per ssh und Webinterface erreichbar

  • um da per GUI dranzukommen, müssten also die Teilnehmer erstmal Software auf ihren (privaten oder dienstlichen) PCs installieren…

Viel entscheidender ist aber m.E.:

psql ist für den PostgreSQL-DBA, was vi für den U\*\*X-Admin ist:

  • auf jeder PostgreSQL-Maschine verfügbar
  • minimalistisch, aber gleichzeitig unglaublich leistungsfähig
  • ich muss das sowieso zu nennenswerten Teilen beherrschen, z.B.
    • für den Fall, dass mir die Firewall einen Streich spielt
    • wenn ich mal als Superuser in die DB will/muss (max_connections= ausgeschöpft)
    • um Dinge zu scripten

Wenn mir jemand erzählt, er oder sie sei UNIX-Admin, dann aber einen nano benutzt, bin ich sofort (zurückhaltend ausgedrückt) skeptisch.

Ähnlich ist es mit psql. Ich muss (als DBA) sowieso wissen, wie ich damit z.B. Objekte anzeigen, DDL einspielen, ggfs. mal eine Stored procedure umschreiben etc. pp. kann. Wenn ich die Software also sowieso (halbwegs) beherrschen muss, kann ich sie doch auch gleich benutzen? Ich sehe nur wenige Szenarien, in denen ein(e) DBA von einem GUI profitieren würde.

Ein(e) AnalystIn hingegen wird die DB wahrscheinlich eher direkt an ein Reporting-Tool oder M$ Excel anbinden wollen.

Bleibt der/die (SQL-) EntwicklerIn. Ja, fair enough, da sehe auch ich gewissen Charme (üblicherweise F5 drücken, um das SQL im Fenster (erneut) laufen zu lassen). Auf der anderen Seite ist derselbe Effekt in psql durch Eingabe von \e zu erreichen, und da kommt ein vi. Der ist ja bekanntlich minimalistisch, aber… 😉

Und ob man DDL jetzt per GUI erzeugen sollte, darüber scheiden sich ja auch die Geister… IMHO eher nicht.

Fazit:

“I never leave the house without it!”

psql ist der vi(m) der PostgreSQL-Welt. Unfassbar flexibel und leistungsfähig, immer verfügbar und dadurch absolutes “Pflichtprogramm”.

P.S.

Ich habe mal jemanden kennengelernt, der eine U\*\*X-Consulting-Firma betrieb und lt. eigener Aussage nur Menschen anstellte, die den ed beherrschen. So weit würde ich dann auch nicht gehen… 😉

P.P.S.

Vielleicht hat die Abneigung gegen TUIs was mit Oracles SQL*Plus (TM) zu tun? Wäre absolut nachvollziehbar, das fasse ich auch nur mit der Kneifzange an…

 

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.

Ceph OSDs mit BlueStore erstellen

by | Sep 23, 2020 | ,

BlueStore ist das neue Speicher-Backend für Ceph ab Luminous. v12.2.x. Es wird standardmäßig verwendet, wenn neue OSDs durch ceph-disk, ceph-deploy oder ceph-volume erzeugt werden.

Es bietet einen großen Vorteil in Bezug auf Leistung, Robustheit und Funktionalität gegenüber dem bisherigen Ansatz.

Bei einer SSD erzeugt man die OSD mit BlueStore zusammen mit dem Journal (DB/WAL). Ist die Festplatte allerdings eine HDD, dann ist man gut damit beraten wenn man das Journal auf eine extra SSD packt. Für den BlueStore-Cache sollte man 1 GB für Festplatten-gestützte OSDs und 4 GB für SSD-gestützte OSDs an RAM einplanen.

Beispiel1: Festplatte ist eine SSD und wurde als sdh erkannt.

[bash]:~# ceph-deploy osd create –data /dev/sdh[/bash]

Eine andere Möglichkeit ist manuell auf dem Node selbst.

[bash]:~# ceph-volume lvm create –data /dev/sdh[/bash]

[bash]
:~# dmesg
…
–> ceph-volume lvm activate successful for osd ID: 10
–> ceph-volume lvm create successful for: /dev/sdh
[/bash]

 

Beispiel2: Festplatte ist eine HDD und wurde als sdh erkannt. Die SSD für das Journal wurde als sdb erkannt.

Wir erzeugen auf der SSD eine Volume Group, die wir z.B. ceph-wal nennen. Diese kann dann auch für alle weiteren Journals verwendet werden.

[bash]:~# vgcreate ceph-wal /dev/sdb[/bash]

Dann erzeugen wir eine Volume Group mit einem Logical Volume auf der HDD.

[bash]
:~# vgcreate ceph-block-h /dev/sdh
:~# lvcreate -l 100%FREE -n block-h ceph-block-h
[/bash]

Nun erzeugen wir ein Logical Volume mit einer Größe von z.B. 10GB

[bash]:~# lvcreate -L 10GB -n wal-b ceph-wal[/bash]

Nun erzeugen wir die OSD mit dem dazugehörigen WAL Device.

[bash]:~# ceph-volume lvm create –bluestore –data ceph-block-h/block-h –block.wal ceph-wal/wal-b[/bash]

[bash]
:~# dmesg
…
Running command: /bin/systemctl start ceph-osd@10
–> ceph-volume lvm activate successful for osd ID: 10
–> ceph-volume lvm create successful for: ceph-block-h/block-h
[/bash]

Martin Schuster
Martin Schuster
Senior Systems Engineer
Martin gehört zu den Urgesteinen bei NETWAYS. Wenn keiner mehr weiss, warum irgendwas so ist, wie es ist, dann wird Martin gefragt. Er hat es dann eigentlich immer mal schon vor Jahren gesehen und kann Abhilfe schaffen :). Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren oder zieht einfach um und fängt von vorne an.
Read more from Martin and meet the Team

Putty mit tmux

by | Sep 11, 2020 | , ,

Nachdem ich öfters mit dem Tool Putty  zu tun bekommen habe, um mich von einer Windows-Umgebung auf einen Linux-Host zu verbinden, habe ich recherchiert wie man beim verbinden einer SSH-Session von Putty direkt eine Tmux-Session auf dem Linux-Server eröffnen kann.
Also habe ich mich mit den Einstellungen von Putty etwas näher befasst, getestet und siehe da es geht doch, dann dachte ich mir, das interessiert doch bestimmt mehr SysAdmins.
Öffnet man Putty, sieht man die Session mit der Liste von Hosts und Links in der Sidebar verschiedene Dropdown-Punkte unter anderem den Punkt SSH, diesen wenn man anwählt kann man einige Einstellung vornehmen unter anderen “Remote command” und hier trägt man “exec tmux” ein und speichert das beim Host ab und schwups hat mein beim nächsten SSH-Login eine Tmux-Session parat, Klasse. Dann viel Spaß beim ausprobieren.

Siehe Screenshot:
Und denkt daran immer schön weiterbilden, wir haben hier tolle Trainings im Bereich OpenSource und die Macht wird mit Dir sein.

Johannes Carraro
Johannes Carraro
Senior Systems 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 Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.
Read more from Johannes and meet the Team

GitLab – Merge Requests

by | Aug 19, 2020 | ,

Merges werden verwendet, um den Code zwischen anderen Personen, die Sie an einem Projekt vorgenommen haben, auszutauschen und die Änderungen einfach miteinander zu konsolidieren.

Schritt 1: Vor dem Erstellen einer neuen Merge sollte im GitLab ein Branch erstellt werden.
Schritt 2: Melden Sie sich bei Ihrem GitLab-Konto an und gehen Sie zu Ihrem Projekt im Abschnitt Projekte.

Schritt 3: Klicken Sie auf die Registerkarte Merge und dann auf die Schaltfläche Neue Merge.

Schritt 4: Um den Request zu mergen, wählen Sie den Quell-Branch und den Ziel-Branch aus der Dropdown-Liste aus und klicken Sie dann auf die Schaltfläche Zweige vergleichen und fortfahren, wie unten gezeigt.

Merge kann verwendet werden, um den Code zwischen anderen Personen, die Sie an einem Projekt vorgenommen haben, auszutauschen und die Änderungen einfach mit ihnen zu besprechen.

Schritt 5: – Sie sehen den Titel, die Beschreibung und andere Felder wie Zuweisen des Benutzers, Festlegen des Meilensteins, Beschriftungen, Name des Quell-Branches und Name des Ziel-Branches und klicken auf die Schaltfläche “Merge senden”

Schritt 6: – Nach dem Absenden der Merge wird ein neuer Bildschirm für Merge angezeigt (siehe unten).

Noch kein Gitlab? Jetzt bei uns im NWS anmelden und Gitlab sorgenfrei 30 Tage lang testen.

Ansible Host-Gruppen: Wer gehört zu wem?

by | Aug 14, 2020 | , , , ,

Immer wieder kommt es vor, dass ich in größeren Ansible-Umgebungen arbeite. Diese enthalten eine Vielzahl von verschiedenen Gruppen im Inventory, die sich auch mal aus anderen Host-Gruppen zusammen setzen. Da ist es nicht immer leicht den Überblick zu behalten.
Da kommt es schon mal vor, prüfen zu wollen oder zu müssen ob alle Gruppen richtig aufgebaut sind oder korrekt interpretiert werden.
Nach ein wenig Recherche war auch schnell mit einem einfachen Ein-Zeiler eine Lösung gefunden, um sich anzeigen zu lassen in welcher Gruppe die einzelnen Server einsortiert sind oder wie sich die Gruppe im Ansible-Inventory zusammen setzt

[code lang=”plain”]
ansible -i <inventory> localhost -m debug -a ‘var=groups’
[/code]

Dabei lässt sich entweder das Inventory-Verzeichnis oder eine konkrete Inventory-Hostdatei angeben.
Und weil es mit einem Beispiel immer besser ist:

[code lang=”bash”]
ansible -i hosts localhost -m debug -a ‘var=groups’
localhost | SUCCESS => {
"groups": {
"all": [
"maja42310",
"maja42444",
"willy1334",
"willy24242",
"koenigin_blau"
],
"drohnen": [
"willy1334",
"willy24242"
],
"honigbienen": [
"maja42310",
"maja42444"
],
"honigbienenvolk": [
"maja42310",
"maja42444",
"willy1334",
"willy24242",
"koenigin_blau"
],
"koenigin": [
"koenigin_blau"
],
"ungrouped": []
}
}
[/code]

Da ich mir das nun mehr als ein mal nicht merken konnte, dachte ich mir ich schreib das mal hier auf. Vielleicht hilft es ja dem ein oder anderen und ich kann es mir jetzt besser merken:)

Wenn Ihr noch mehr über Ansible erfahren wollt, dann besucht doch einfach eines unserer Trainings bei Netways Events. Sollte es schon etwas konkreter sein und Ihr benötigt gezielt Hilfe, fragt doch gerne unsere Kollegen vom Sales Team ob Ihr nicht Unterstützung von Netways Professional Service bekommt.

Daniel Neuberger
Daniel Neuberger
Senior Consultant
Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.
Read more from Daniel and meet the Team

Trainings

Web Services

Events