Vergiss awk und perl! Gerade, wenn es um das Verarbeiten einfacher Textdaten oder Textdateien geht, ist es oft effizienter, Standard-Mechanismen der Bash zu verwenden.
Nimm dir ein paar Minuten Zeit - ich habe dir hier dafür die wichtigsten Mechanismen zusammengestellt und erklärt. Mehr brauchst Du nicht, um in eigenen Shell-Skripten robust und effizient Textdaten zu verarbeiten.
Dir ist egal, warum das alles funktioniert? Du willst einfach schnelle Ergebnisse? Dann überspringe den ersten Teil und schaue dir direkt die Beispiele und Performance-Tests an.
Die Beispiele kannst du direkt im Browser ausprobieren und verändern.
Und plötzlich ist es doch wieder passiert: Ich habe sensible Informationen - diesmal ein Passwort - auf der Kommandozeile der Bash eingetippt.
In ihrer unendlichen Hilfsbereitschaft hat die Shell sofort die so abgesetzte Kommandozeile in ihrer History vermerkt. So kann ich sie später problemlos noch einmal verwenden …
Dumm nur, wenn sich das betroffene System nicht unter meiner vollständigen Kontrolle befindet (Kundensystem?), oder wenn mir beim nächsten Mal jemand über die Schulter schaut, während ich die History nach einem anderen Befehl durchsuche.
Die betreffende Zeile muss also aus der History entfernt werden.
Wie stellt man das am besten an, und
Wie verhindert man das Problem in Zukunft?
Generell hast Du zwei Möglichkeiten, Befehle aus der Bash-History zu entfernen. Entweder, verwendest direkt das history-Kommando, oder Du bearbeitest die ~./bash_history.
Google stellt mit der Cloud Shell ein sehr nützliches Werkzeug zur Verfügung: Direkt aus dem Browser heraus hat man Zugriff auf eine Linux-Shell, in der man im Prinzip alles machen kann, was man auf einer Linux-Shell eben so tut.
Ich verwende die Cloud Shell z.B. oft als Sprungbrett, um mich per SSH auf andere Systeme zu verbinden. Dabei ist mir neulich aufgefallen, dass ein einfaches Port-Forwarding “out-of-the-box” nicht funktioniert: Beim Versuch, eine SSH-Verbindung mit lokalem Port-Forwarding aufzubauen (ssh user@zielhost -L 8080:127.0.0.1:8080), erscheint nach dem Verbindungsaufbau folgende Fehlermeldung:
bind: Cannot assign requested address
und das Port-Forwarding wird nicht aufgebaut.
Der Grund dafür ist recht simpel: SSH versucht sich für das TCP-Forwarding an den lokalen IPv6-Port zu binden. Das ist in der Google Cloud Shell aktuell nicht möglich und schlägt deshalb fehl.
Let's Encrypt ist ein Projekt, mit dessen Hilfe sich jeder kostenlose SSL-Zertifikate ausstellen lassen kann. Die so ausgestellten Zertifikate werden von allen aktuellen Clients akzeptiert und können sowohl für Webserver als auch für andere SSL-basierte Dienste verwendet werden (smtp mit TLS, ldaps, ...).
Bei den von der Let's Encrypt CA ausgestellten Zertifikaten handelt es sich um sogenannte Domain-validierte Zertifikate. Das bedeutet, dass bei der Ausstellung überprüft wird, ob der Antragsteller die Kontrolle über den im Zertifikat angegebenen Domainnamen hat. Dazu muss der Antragsteller nachweisen, dass er unter dem im Zertifikat aufgeführten Hostnamen Dateien mit beliebigen Namen und Inhalten per Webserver veröffentlichen kann.
Ein großer Vorteil neben dem Preis ist die komplette Automatisierung der SSL-Konfiguration durch Let's Encrypt:
Erzeugen eines private-Key und eines Zertifikats-Request
Einreichen des Zertifikats-Request bei der Let's Encrypt CA
Domain-Validierung
Einbinden des Zertifikats in die Webserver-Konfiguration
Seit 3. Dezember 2015 befindet sich die Let's Encrypt Infrastruktur in der öffentlichen Beta-Phase, so dass jeder das Ausstellen eigener Zertifikate testen kann.
Wie yellow-bricks berichtet, wird bei VMware an einem Projekt gearbeitet, mit dem ESXi-Server direkt aus dem Browser heraus verwaltet werden können.
Auf der Projektwebsite steht eine Technical Preview zum Download bereit. Dabei handelt es sich um ein vib-Paket, dass direkt auf dem ESXi-Server installiert wird. Anschließend reich ein hinreichend aktueller Browser mit aktiviertem Javascript, um folgende Operationen auf dem ESXi-Server auszuführen:
Steuerung von virtuellen Maschinen (an-/ausschalten, reset, ...)
Das musste ich natürlich gleich ausprobieren. Um es vorweg zu nehmen: ich bin begeistert! Endlich kann ich von meinem Chromebook aus direkt auf ESXi-Server zugreifen und dort virtuelle Maschinen steuern und verwalten.
Aktuell läuft der "ESXI Embedded Host-Client" ausschließlich unter ESXi 6.0 und (wenn veröffentlicht) unter ESXi 5.5u3. Für meine Tests habe ich mir einen "leeren" ESXi-Server 6.0 eingerichtet und das Paket per SSH installiert:
Habt Ihr Euch schon mit IPv6 auseinandergesetzt? Ich meine nicht nur in der Theorie - ich meine in der Praxis. Habt Ihr ein Gefühl dafür, wie sich die Stateless Address Autoconfiguration (SLAAC) verhält, wie Router Advertisements funktionieren oder wie das Neighbor-Discocery-Protocoll ARP ersetzt? Braucht Ihr bei IPv6 noch DHCP? Was genau ändert sich im DNS? Wie könnt Ihr am besten IPv6 parallel zu bestehenden IPv4-Diensten betreiben.
Ich selber wurde vor kurzem gebeten, zwei Workshops zum Thema IPv6 durchzuführen. Für diese Workshops wollte ich eine Demo-Umgebung bereitstellen. Gleichzeitig wollte ich - meine letzten Workshops zu diesem Thema sind schon eine Weile her - mein KnowHow zu diesem Thema wieder etwas auffrischen und auf den aktuellen Stand bringen.
Mit Ravello habe ich eine Lösung entdeckt, die auch für Euch interessant sein könnte: Mit Ravello lassen sich komplette Layer-2 Netze in den Cloud-Umgebungen von Google oder Amazon realisieren. Perfekt für alle, die - wie ich - viel von unterwegs arbeiten und zu faul sind, leistungsstarke Notebooks für den performanten Betrieb solcher Testumgebungen mit sich herumzutragen ;-)
In diesem Artikel möchte ich Euch zeigen, wie Ihr mit Ravello eine IPv6-Testumgebung realisiert, die Ihr mit SixXS an den IPv6-basierten Teil des Internet anbinden könnt.
Ich verwende auf dieser Website Cookies, um den Datenverkehr zu analysieren und so den Inhalt über die Zeit zu optimieren. (für Details dazu, siehe meine Datenschutzerklärung)
