{ "version": "2.0", "xmlns": { "atom": "http://www.w3.org/2005/Atom", "content": "http://purl.org/rss/1.0/modules/content/", "georss": "http://www.georss.org/georss", "gml": "http://www.opengis.net/gml" }, "channel": { "title": "fboës - Der Blog | Artikel mit dem Tag \"Bash\"", "link": "https://journal.3960.org/", "description": "Programmierung, Luft- & Raumfahrt, Kurioses: Der Blog von und mit Frank Boës.", "language": "de-DE", "copyright": "© 2008-2023 Creative Commons BY", "atom_link": { "href": "https://journal.3960.org/tagged/bash/rss.json", "rel": "self", "type": "application/rss+json" }, "lastBuildDate": "Fri, 22 Mar 2024 18:00:20 +0100", "atom_updated": "2024-03-22T18:00:20+01:00", "generator": "blogophon", "image": { "url": "https://cdn.3960.org/images/tile-128x128.png", "title": "fboës - Der Blog", "link": "https://journal.3960.org/" }, "items": [ { "title": "SSH-Schlüssel unter Windows – das komplette Programm", "description": "
SSH-Schlüssel sind die Eintrittskarte für SSH, Git, und viele andere darauf aufbauende, nützliche Dienste, die ein Programmierer nutzen möchte. Während unter Linux und Mac OSX das Erzeugen eines SSH-Schlüssels eine schmerzlose Sache ist, sind unter Windows mehr Handgriffe gefragt, um alle Anwendungsfälle eines SSH-Schlüssels abbilden zu können – unter anderem für die Verwendung des selben Schlüssels aus einer Virtualisierung wie zum Beispiel VirtualBox oder Docker.
", "content_encoded": "SSH-Schlüssel sind die Eintrittskarte für SSH, Git, und viele andere darauf aufbauende, nützliche Dienste, die ein Programmierer nutzen möchte. Während unter Linux und Mac OSX das Erzeugen eines SSH-Schlüssels eine schmerzlose Sache ist, sind unter Windows mehr Handgriffe gefragt, um alle Anwendungsfälle eines SSH-Schlüssels abbilden zu können – unter anderem für die Verwendung des selben Schlüssels aus einer Virtualisierung wie zum Beispiel VirtualBox oder Docker.
\n\nGenerell gibt es zwei Arten, unter Windows einen SSH-Schlüssel zu speichern:
\nppk
)Viele Anleitungen beschränken sich auf die eine oder andere Methode zum Anlegen von SSH-Schlüsseln. Tatsächlich macht es aber unter Windows sehr viel Sinn, den eigenen Schlüssel in beiden Formate verfügbar zu haben. Das geht deutlich schmerzloser, wenn beide Schlüsselformate in einem Aufwasch angelegt werden.
\nputtygen
Schlüsselgenerator, pageant
Schlüsselagenten und das plink
SSH-Verbindungstool.mkdir -p ~/.ssh
angelegt werden.C:\\Users\\USERNAME\\.ssh
) die insgesamt drei Dateien anzulegen, die zusammen alle Schlüssel-Komponenten darstellen.In PuttyGen selber wird es nun etwas trickreich:
\nC:\\Users\\USERNAME\\.ssh\\id_rsa.ppk
speichern.C:\\Users\\USERNAME\\.ssh\\id_rsa.pub
einfügen (mit der Funktion „Save public key“ wird der Public Key nicht im korrekten Format exportiert).C:\\Users\\USERNAME\\.ssh\\id_rsa
speichern. Wichtig ist hierbei, dass keine Dateiendung verwendet wird.In eurem SSH-Verzeichnis C:\\Users\\USERNAME\\.ssh
sollten nun mindestens drei Dateien liegen:
id_rsa.ppk # Privater / öffentlicher Schlüssel für PuTTY\nid_rsa.pub # Öffentlicher Schlüssel für OpenSSH\nid_rsa # Privater Schlüssel für OpenSSH\n
\nSpäter werden in diesem Verzeichnis ggf. noch mehr Dateien auftauchen, wie z.B. known_hosts
, authorized_keys
und config
.
Übrigens solltet ihr mit der Git Bash mittels chmod 644 ~/.ssh/* && chmod 600 ~/.ssh/id_rsa
allen Dateien die korrekten Zugriffsrechte (-rw-r--r--
bzw. -rw-------
) geben, falls dies nicht schon geschehen ist.
Den öffentlichen Schlüssel könnt ihr nun auf allen Servern und Diensten bekannt machen, mit denen ihr euch später verbinden wollt. Auf eurem Rechner wiederum wird die Git Bash automatisch den privaten OpenSSH-Schlüssel verwenden, während andere Programme den privaten Schlüssel aus der id_rsa.ppk
entweder in den Einstellungen übergeben bekommen müssen, oder aber aus einem vorher zu startenden pageant
Schlüsselagenten übernehmen können. Falls ihr SSH-Schlüssel für eure tägliche Arbeit benutzt, könnt ihr den Pageant auch automatisch starten und den Schlüssel laden lassen.
Viele Windows-Programme können so euren SSH-Schlüssel nutzen, u.a.:
\nSo oder so seid ihr nun mit beiden Schlüsselformaten ausgestattet, so dass z.B. auch der Wechsel des Betriebssystems oder die Verwendung von Virtualisierung euch die Weiterbenutzung eures SSH-Schlüssels erlaubt.
\nUnter Linux und Mac OSX ist der Vorgang übrigens etwas kürzer:
\nssh-keygen -t rsa -b 4096 -C "YOUR@EMAIL"\n
",
"link": "https://journal.3960.org/posts/2019-12-30-ssh-schluessel-unter-windows-komplett/",
"pubDate": "Mon, 30 Dec 2019 18:52:10 +0100",
"atom_published": "2019-12-30T18:52:10+01:00",
"atom_updated": "2020-07-29T07:07:13+02:00",
"guid": "user/posts/2019-12-30-ssh-schluessel-unter-windows-komplett/index.md",
"author": "info@3960.org (Frank Boës)",
"categories": [
"Für Tumblr",
"Programmierung",
"Webdevelop",
"Git",
"Bash",
"Anleitung"
]
},
{
"title": "Schnelle Deployments mit Gitlab",
"description": "Ihr habt eine Gitlab-Instanz in eurer Firma stehen? Ihr wollt mit Deployments anfangen, habt aber keine Lust auf Jenkins? Überraschung: Mit Gitlab könnt ihr auch Deployments durchführen!
", "content_encoded": "Ihr habt eine Gitlab-Instanz in eurer Firma stehen? Ihr wollt mit Deployments anfangen, habt aber keine Lust auf Jenkins? Überraschung: Mit Gitlab könnt ihr auch Deployments durchführen!
\n\nSchon lange sind die Zeiten vorbei, in denen man einfach via FTP Dateien vom heimischen Rechner auf den Kundenserver hochschieben sollte. Wenn ihr händisch mittels rsync
oder git
Quellcode auf Develop-, Staging- oder Produktiv-System schiebt, ist der Sprung zu einem automatischen Deployment gar nicht mehr so weit, wenn ihr Gitlab verwendet.
Warum solltet ihr automatische Deployments verwenden?
\nNachfolgend findet ihr ein Deployment via git
, ohne weitere Zusätze. Nachdem das Prinzip verstanden ist, kann das Rezept auch für rsync
, npm
, composer
oder jede andere Form von Transportmethode angepasst werden, und um beliebige andere schlaue Handgriffe erweitert werden.
Ein Git-Deployment sieht für euch normalerweise wie folgt aus:
\ngit clone
das Projekt ausgecheckt war.git pull
(plus ggf. weitere Kommandos durch).Genau diese Handgriffe führt ein Gitlab-Deployment für euch automatisch durch, wenn bestimmte Bedingungen im Git erfüllt sind. In der Regel ist diese Bedingung ein Commit in einen bestimmten Branch, oder das Auftauchen eines neuen Tags.
\nFalls ihr der ganzen Automatik nicht traut, könnt ihr auch festlegen, dass das Deployment mit einem Knopf aus dem Webfrontend von Gitlab gestartet wird.
\nDreh- und Angelpunkt ist das installierte Gitlab-CI-Modul von Gitlab. Dies wird eurer lokalen Gitlab-Installation hinzugefügt. Danach könnt ihr jedes eurer Projekte mit einer Datei namens gitlab-ci.yml
ausstatten, in der ihr das Deployment beschreibt.
Meine Vorlage dafür sieht inzwischen wie folgt aus:
\n# Never use Docker image without pinned version\nimage: governmentpaas/git-ssh:f120938e7390ec36314ec037465a1b35a079243e\n\nbefore_script:\n - eval $(ssh-agent -s)\n - mkdir -p ~/.ssh\n - echo "${SSH_CONFIG}" > ~/.ssh/config\n - echo "${SSH_KNOWNHOSTS}" > ~/.ssh/known_hosts\n - ssh-add <(echo "${SSH_PRIVATEKEY}")\n\n# Hier könnte Testing durchgeführt werden.\n# Das Deployment wird nur durchgeführt, wenn der Test erfolgreich ist.\n# test:\n# image: cytopia/eslint\n# stage: test\n# only:\n# - master\n# - merge_requests\n# script:\n# - tools/ci/test.sh\n\ndeploy_production:\n stage: deploy\n environment:\n name: production\n url: ${PRODUCTION_URL}\n variables:\n ENVIRONMENT_HOST: ${CI_ENVIRONMENT_NAME}\n ENVIRONMENT_DIR: ${PRODUCTION_DIR}\n ENVIRONMENT_URL: ${PRODUCTION_URL}\n only:\n - master\n # - tags\n # when: manual\n script:\n #- ssh ${ENVIRONMENT_HOST} "cd ${ENVIRONMENT_DIR} && echo 'Start DB backup...'"\n - ssh ${ENVIRONMENT_HOST} "cd ${ENVIRONMENT_DIR} && git pull && git checkout ${CI_COMMIT_SHA} ."\n #- ssh ${ENVIRONMENT_HOST} "cd ${ENVIRONMENT_DIR} && echo 'Clear cache...'"\n\n# deploy_staging:\n# deploy_develop:\n# Hier könnten weitere Deployments für andere Zielsysteme stehen,\n# die man einfach von "deploy_production" kopieren kann\n
\nIn dem Skript sind die Schritte für Building und Testing aktuell ausgeklammert, können von euch aber einfach aktiviert werden. Der eigentliche Clou ist hier, dass Gitlab mit einigen von euch hinterlegten Variablen in der letzten Zeile der Datei aufgefordert wird, eine SSH-Verbindung zu dem Zielhost aufzumachen und dort ein git checkout
durchzuführen.
Die eigentliche Magie ist dabei, dass Gitlab exakt den aktuellen ausgewählten Commit auf dem betreffenden Zielsystem auscheckt. Mit der direktive only
legt ihr z.B. einen bestimmten Branch oder ein Tag fest, mit when: manual
eine manuelle Ausführung. Und im Falle eines verpfuschten Deployments, könnt ihr aus dem Gitlab-Webfrontend auch einen älteren Commit deployen lassen!
Das Deployment-Skript lässt sich natürlich um weitere Kommandos erweitern, die man auf dem Zielsystem ausführen möchte. Caches leeren, Composer ausführen oder Backups anlegen – all dies kann man hier problemlos hinzufügen. Und außerdem sehr ihr bereits, wie man z.B. für ein Develop- oder Staging-System das Skript erweitern könnt. Mehr Informationen über das Thema findet ihr in der offizielen Gitlab-CI-Dokumentation.
\nDas obige Deployment-Skript ist ohne große Änderungen für viele Projekte verwendbar. Pro Projekt hinterlegt man in Gitlab nur noch ein paar Pipeline-Settings:
\nVariable | \nInhalt | \n
---|---|
SSH_CONFIG | \nHier muss eine SSH-Config z.B. für production hinterlegt werden. Siehe unten. | \n
SSH_KNOWNHOSTS | \nHier muss das Ergebnis von ssh-keyscan [-p PORT] HOSTNAME für jeden der Hosts in SSH_CONFIG hinterlegt werden. | \n
SSH_PRIVATEKEY | \nDer SSH-Key, mit dem sich Gitlab zum Produktions-System verbinden darf. | \n
PRODUCTION_URL | \nDie URL, unter der das Produktions-System erreichbar ist. | \n
PRODUCTION_DIR | \nDer Pfad, in dem die Produktions-Installation liegt. | \n
Die letzten drei Variablen kann man ggf. noch für DEVELOP_
und STAGING_
ausführen.
Die Variable SSH_CONFIG
benutzt einen kleinen Trick, um die für das Deployment notwendigen SSH-Zugangsdaten zu speichern: Eine sehr kompakte Art und Weise, um Serverdaten inklusive Ports, Benutzernamen und IPs aufzulisten, ist die SSH-Config. Für Gitlab kann man dieses Format ganz wunderbar verwenden, um die Server-Konfiguration für die Deployment-Server in einer Pipeline-Variable zu hinterlegen.
Host production\n Hostname 192.168.178.12\n Port 22\n User www-data\n
\nZu beachten ist dabei, dass in der SSH-Config keine Passwörter gespeichert werden können. Das ist aber auch in Ordnung, da man sinnigerweise die Authentifizierung des Zugangs über einen SSH-Schlüssel durchführt.
\nNachdem all diese Handgriffe vollbracht sind, könnt ihr im Idealfall 30 Sekunden nach eurem Commit bereits euren Quellcode auf der jeweiligen Zielumgebung bewundern. Projektmanager und Tester werden es euch danken, jederzeit den aktuellsten Stand auf dem Entwicklungssystem vorzufinden – und ihr werdet es euch selber danken, beim Deployment nicht das Backup vergessen zu haben. 😉
\nAußerdem müsst ihr dem Rest des Teams nicht großartig erklären, wie Deployments jetzt funktionieren: Jedes Teammitglied, dass Git benutzt, kann ohne weiteres Vorwissen mustergültige Deployments hinlegen.
\nUpdate: Inzwischen gibt es eine überarbeitete Version des Artikels „Fehlerfreie Gitlab-Deployments für Shopware & Co“ auf den Seiten meines Arbeitgebers.
", "link": "https://journal.3960.org/posts/2017-11-20-schnelle-deployments-mit-gitlab/", "pubDate": "Mon, 20 Nov 2017 19:00:00 +0100", "atom_published": "2017-11-20T19:00:00+01:00", "atom_updated": "2020-01-23T14:53:21+01:00", "guid": "user/posts/2017-11-20-schnelle-deployments-mit-gitlab.md", "author": "info@3960.org (Frank Boës)", "categories": [ "Git", "Webdevelop", "Programmierung", "Bash" ] }, { "title": "Der Bookmark-Manager für SSH-Zugangsdaten", "description": "Als Programmierer hat man mit einer Vielzahl von SSH-Hosts zu tun, mit denen man sich verbinden muss, um dort seinen Aufgaben nachzugehen. Mit einem kleinen Hilfsmittel müsst ihr euch in Zukunft keine komplizierten Host-Namen mehr merken.
", "content_encoded": "Als Programmierer hat man mit einer Vielzahl von SSH-Hosts zu tun, mit denen man sich verbinden muss, um dort seinen Aufgaben nachzugehen. Mit einem kleinen Hilfsmittel müsst ihr euch in Zukunft keine komplizierten Host-Namen mehr merken.
\n\nDreh- und Angelpunkt dafür ist das ~/.ssh
-Verzeichnis. Dieses Verzeichnis wird von vielen Programmen auf eurem Rechner als Quelle für SSH-Informationen verwendet. U.a. sind diese Programme:
Da alle regulär in diesem Verzeichnis liegenden Dateien einfache Textdateien sind, dienen sie gleichzeitig auch als Dokumentation für euch selber.
\nUnter Mac OSX bzw. Linux existiert dieses Verzeichnis in der Regel bereits. Auch unter Windows solltet ihr dieses Verzeichnis in eurem Benutzer-Ordner anlegen, was aber nur über die Eingabeaufforderung mit folgender Zeile funktioniert.
\ncd %USERPROFILE%\nmkdir .ssh\n
\nIn diesem Verzeichnis legt ihr unter anderem auch eure SSH-Schlüssel ab, und unter Windows die von PuttyGen erzeugte PPK-Datei, die man sinnigerweise id_rsa.ppk
nennt.
In diesem Verzeichnis wird sich später auch die Datei known_hosts
anlegen, in der alle Informationen über von euch als vertrauenswürdig eingestufte SSH-Hosts hinterlegt werden.
Unter Windows solltet ihr GitBash als Terminal-Programm verwenden, um die volle Power dieser Dateien nutzen zu können.
\nIn dem SSH-Verzeichnis erzeugt ihr nun einen Datei namens config
– dies ist die SSH-Config-Datei. Euer .ssh
-Verzeichnis sollte nun wie folgt aussehen:
config\nid_rsa\nid_rsa.ppk # Windows\nid_rsa.pub\nknown_hosts\n
\nIn die SSH-Config-Datei kommen nun die Verbindungsdaten für Hosts, die ihr euch merken (oder vereinfachen) wollt. Eine SSH-Config ist eine einfache Textdatei, in der ihr für jeden Host ein paar Zeilen Konfiguration hineinschreibt. Das Format ist dabei denkbar einfach und selbsterklärend:
\nHost *.secret-site.com\n User dwayne\n Port 2020\n\nHost my-blog blog.example.com\n Hostname 192.168.178.12\n Port 2222\n User wayned\n\n# --------------------------------------\n# Fallback\nHost *\n User www-data\n ServerAliveInterval 5\n ServerAliveCountMax 10\n
\nNeben IPs, Hostnamen, Benutzernamen und Ports kann man eigentlich alle relevanten Informationen für eine SSH-Verbindung ablegen – mit Ausnahme eines Passworts. Da ihr SSH-Verbindung aber sowieso über einen SSH-Schlüssel aufbauen solltet, ist dies keine wirkliche Einschränkung.
\nMit dem obigen Beispiel kann man sich ab sofort eine Menge Tipparbeit sparen. Statt länglicher Kombinationen aus Benutzernamen, IPs und Ports könnt ihr (und jeder der oben genannten Programme) den von euch definierten Shortcut aufrufen:
\n$ ssh -p 2222 wayne@192.168.178.12 # vorher\n$ ssh my-blog # nachher\n
\nDas Tolle ist: Die SSH-Config-Datei ist nicht nur ein Shortcut und Bookmark, sondern dient eurer eigenen Dokumentation aller eurer Verbindung. Außerdem kann man sich ein relativ einfaches System überlegen, um z.B. projektspezifische Hostnamen einfach zu standardisieren:
\n# --------------------------------------\n# Projekt A\nHost PROJECTA-develop\n # ... Konfiguration\n\nHost PROJECTA-staging\n # ... Konfiguration\n\nHost PROJECTA-production\n # ... Konfiguration\n\n# --------------------------------------\n# Projekt B\nHost PROJECTB-develop\n # ... Konfiguration\n\nHost PROJECTB-staging\n # ... Konfiguration\n\nHost PROJECTB-production\n # ... Konfiguration\n
\nFindige Naturen erkennen hier natürlich schöne Ansätze, um projektübergreifende Deployment-Tools zu entwickeln. 😉
\nÜbrigens: Dieses Format eignet sich auch hervorragend zur Dokumentation von SSH-Zugangsdaten in Teams. So könnt ihr z.B. in Wikis SSH-Zugangsdaten hinterlegen, die der nächste Entwickler nur noch per Copy und Paste bei sich einfügen muss. Damit könnt ihr auch sicher stellen, dass alle Mitglieder eures Teams die selben Hostnamen verwenden, und z.B. interne Tools sich auf bestimmte Hostnamen verlassen können.
\nMehr Details über die vielen Möglichkeiten von SSH-Configs findet ihr in der hervorragenden Anleitung zur Konfiguration der SSH-Config.
", "link": "https://journal.3960.org/posts/2017-11-18-bookmark-manager-fuer-ssh-zugangsdaten/", "pubDate": "Sat, 18 Nov 2017 19:00:00 +0100", "atom_published": "2017-11-18T19:00:00+01:00", "atom_updated": "2018-07-18T23:24:28+02:00", "guid": "user/posts/2017-11-18-bookmark-manager-fuer-ssh-zugangsdaten.md", "author": "info@3960.org (Frank Boës)", "categories": [ "Bash", "Programmierung", "Für Tumblr" ] }, { "title": "Das beste chmod aller Zeiten", "description": "Ein Kollege hat mir den besten Weg gezeigt, wie man z.B. einer Gruppe die perfekten Unix/Linux/MacOSX-Dateirechte verpasst.
", "content_encoded": "Ein Kollege hat mir den besten Weg gezeigt, wie man z.B. einer Gruppe die perfekten Unix/Linux/MacOSX-Dateirechte verpasst.
\n\nDas Problem: Dateien müssen nur die Rechte für Lesen & Schreiben haben, Order brauchen noch zusätzlich ein Recht zum Ausführen. Da man nicht unbedingt alle Dateien ausführbar haben will, ergibt sich hier im Endeffekt die Anforderung, für Dateien chmod ugo+rw
und für Verzeichnisse chmod ugo+rwx
auszuführen. Sobald das ganze rekursiv auf einen ganzen Baum angewendet werden soll, kann das sehr kompliziert werden.
Hier also die bahnbrechende Lösung:
\nchmod -R ugo+rwX\n
\nEine sehr gute Zusammenfassung gibt es auch bei der Stackoverflow-Seite zum Thema chmod
.
Übrigens: Der Ausdruck „aller Zeiten“ wird hier nicht leichtfertig verwendet, sondern bezieht sich tatsächlich auf die kommenden Jahrzehnte.
", "link": "https://journal.3960.org/posts/das-beste-chmod-aller-zeiten/", "pubDate": "Tue, 12 Jan 2016 03:00:00 +0100", "atom_published": "2016-01-12T03:00:00+01:00", "atom_updated": "2017-10-05T10:30:19+02:00", "guid": "user/posts/das-beste-chmod-aller-zeiten.md", "author": "info@3960.org (Frank Boës)", "categories": [ "Programmierung", "Bash" ] } ] } }