Select Page

NETWAYS Blog

Kommentar in der Bash History

by | Nov 12, 2020 |

Heute stelle ich euch einen der „billigsten“ Tricks der Linux CLI vor, den erstaunlicherweise fast keiner kennt.

Kennt ihr es nicht auch? Ihr benutzt ein Kommando in der bash und könnt euch das Kommando einfach nicht merken. Das gemeine daran: Wenn ihr euch das Kommando nicht merken könnt, könnt ihr es auch mit Hilfe von Ctrl+r nicht suchen. Also bleibt nur „googeln“ oder mit den Pfeiltasten mühsam nach dem richtigen Kommando suchen.

Eine super Ergänzung dazu ist das Kommentieren von Kommandos.

Ein simples Beispiel:
~$ find . -mtime +30 -print # find files older than 30 days
./.bash_logout
./.bashrc
./.gnupg
./.profile
./.ssh
./.ssh/authorized_keys

Nun kann das Kommando in der Suche der Bash History (Ctrl+r) mit Hilfe des Kommentars gefunden werden:
(reverse-i-search)`older': find . -mtime +30 -print # find files older than 30 days

Zugegeben, das war jetzt sehr billig. Man kann dieses Vorgehen aber noch weiter „aufbohren“ in dem man Platzhalter einfügt. Als etwas komplexeres Beispiel dient hier ein zfs send der einen Snapshot auf einen Backup-Server archiviert und (für bessere Transferraten) mbuffer nutzt.
~$ zfs send -I <last-incremental-snapshot> data/test@<current-incremental-snapshot> | mbuffer -O <backup-server>:<port>   # transfer zfs snapshots to backup server
-bash: syntax error near unexpected token `|'

Durch die Platzhalter bekommt man beim Ausführen des Kommandos leider eine nicht so schöne Fehlermeldung, aber immerhin ist die “Kommando-Vorlage” nun in der Bash History verfügbar.
(reverse-i-search)`backup': zfs send -I <last-incremental-snapshot> data/test@<current-incremental-snapshot> | mbuffer -O <backup-server>:<port>   # transfer zfs snapshots to backup server

Um den unschönen Syntax Fehler und damit verbundene, potentielle Fehler zu vermeiden kann das Kommando auch direkt in die Bash History ($HOME/.bash_history) geschrieben werden. Nach einem Logout / Login oder history -a ist das neue Kommando dann verfügbar.

Solltest ihr viele Kommandos hinterlegen wollen, denkt bitte daran eure Bash-History entsprechend groß zu dimensionieren. Nicht das die “Kommando-Vorlagen” schon nach einem Tag wieder aus der History verschwunden sind.

Falls dieser Tip für euch völlig unverständlich ist kann ich unser Linux Training nur wärmstens empfehlen 😉

Tobias Redel
Tobias Redel
Head of Professional Services
Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker und renoviert, baut und bastelt als Heimwerker an allem was er finden kann.
Read more from Tobias and meet the Team

Squid 4 Proxy mit LDAP & MITM SSL-Bump

by | Oct 15, 2020 |

Im Zuge meiner Ausbildung bei NETWAYS durfte ich mich diese Woche mit Squid auseinandersetzen. Dabei merkte ich, dass man sich bezüglich LDAP & SSL-BUMP wirklich nur auf die offiziellen Squid Dokus und die Red Hat Dokus verlassen konnte.

Squid ist ein Caching Proxy für Web Seiten das HTTP, HTTPS, FTP und vieles mehr unterstützt. Es reduziert Bandbreite und verbessert Aufrufzeiten. Dabei kann es den effektiven Netzwerkdurchsatz verbessern.

  • Es ermöglicht Caching und Verteilung.
  • Es erlaubt Content Filtering.
  • Es unterstützt LDAP-Anbindung für die Authentifizierung.
  • Es kann als transparent / MITM Proxy genutzt werden.

 

 

Ubuntu 20.04.01 Server: Die für SSL Bump benötigten Kompilerflags lauten --enable-ssl-crtd & --with-openssl. Aktuell ist Squid in Version 4 mit diesen Flags in den Ubuntu-Server-Repos nicht vorkompiliert, sodass man man sich Squid praktisch selbst damit bauen muss. Ob die Flags aktiv sind kann man folgendermaßen checken:

$ squid -v | grep ssl

CentOS 8: Unter CentOS kommt Squid direkt mit SSL-Bump vorkompiliert.

  • Der folgende Artikel basiert auf Squid Version 4.4 unter CentOS 8.

 

Vorab-Konfiguration

  • Firewallregeln sollten Squid entsprechend angepasst werden.
$ sudo firewall-cmd --permanent --add-port=3128/tcp
$ sudo firewall-cmd --reload
  • Falls jemand sich wie ich noch nicht so sehr mit SELinux auskennt, empfiehlt es sich die SELinux Policies erstmal auf Permissive zu stellen. Dies geschieht in der /etc/selinux/config. Später nach erfolgreicher Installation sollte man sie wieder zurück auf Enforcing setzen.
SELINUX=permissive

LDAP

  • Das Root Zertifikat der Umgebung muss heruntergeladen, in den Zertifikatsordner des Squid Servers geschoben und aktualisiert werden damit LDAP signiert via TLS funktioniert.
$ sudo cp ROOT_ZERTIFIKAT.cer /etc/pki/ca-trust/
$ sudo update-ca-trust

Die auth_param Parameter sollten schon in der Konfigurationsdatei /etc/squid/squid.conf stehen und entsprechend aktiviert und vervollständigt werden.

  • Wichtig ist es exakt passend Base/Domain/Suchfilter und Server zu übergeben. Hilfreich hierzu sind die Man Page von basic_ldap_auth sowie ldapsearch.
  • Folgendes Beispiel basiert auf einer Microsoft Active-Directory Umgebung was an dem -f Suchparameter erkannt werden kann. Zwingend wichtig ist es hier das %s für den User mitzugeben.
Das –R Flag muss manchmal gesetzt werden um Referrals nicht zu folgen, da ansonsten mehrere Aufrufe stattfinden und Konflikte auslösen womit Squid LDAP verweigern wird.

 

auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "dc=FIRST_DOMAIN,dc=SECOND_DOMAIN,dc=ROOT_DOMAIN"
-D "CN=LDAP/USERNAME,OU=SERVICEGROUP,OU=COMPANY,OU=NET,OU=COMPANY,DC=FIRST_DOMAIN,DC=SECOND_DOMAIN,DC=TOP_DOMAIN"
-w "password" -f "(&(objectCategory=Person)(samAccountName=%s))" -R -H ldaps://FIRST_DOMAIN.SECOND_DOMAIN.TOP_DOMAIN:636
auth_param basic children 5
auth_param basic realm Hi this is your Squid Proxy speaking
auth_param basic credentialsttl 5 minutes
#Falls die LDAP Authentifizierung nicht durching,HTTP Traffic sperren.
acl ldap-auth proxy_auth REQUIRED
http_access deny !ldap-auth

 

  • Jetzt braucht Squid noch einen Neustart
$ sudo systemctl restart squid
  • Innerhalb weniger Sekunden sollte die LDAP/AD Passwortabfrage kommen.

 

read more…

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

Trainings

Web Services

Events