Hobbyseite von diabolus Umarov
Ja, im Moment läuft es!
Das ist nur ein kleines Update, um den Stand der Dinge zu klären.
Zum Einen, ich habe ein paar Änderungen vorgenommen. Sollte ursprünglich noch pqxx für die Verbindung zur Datenbank eingesetzt werden, was unter Windows zu Schwierigkeiten geführt hat, übernimmt nun Qt direkt dieser Arbeit. Das muss jetzt im Code noch umgebaut werden, aber dann geht es zu den Tests auf Windows. Mal die Daumen drücken!
Einen produktiven Fortschritt gibt es jedoch bei der Verschlüsselung. Da habe ich einiges ausprobiert, aber vieles kam mir einfach zu kompliziert vor.
Nun bin ich bei OpenSSL gelandet und das funktioniert hervorragend! Schlüsselgenerierung, Verschlüsselung und Entschlüsselung, alles läuft! Das kann also jetzt für das Programm verwendet werden. Das compilieren unter Windows wurde auch getestet und funktioniert einwandfrei!
Desweiteren habe ich entschieden, keine privaten Nachrichten und Mediendateien auf dem Server zu behalten. Soll heissen, wenn eine Nachricht abgeschickt wird, kommt sie auf den Server. Hat dann der Empfänger die Nachricht abgerufen, wird sie im Anschluss wieder vom Server gelöscht.
Diese Vorgehensweise hat ein paar Vorteile. Der Wichtigste dürfte natürlich sein, sollte irgendwie mal jemand unerlaubt auf die Datenbank zugreifen können, kann er bestenfalls noch ungelesene Nachrichten abgreifen. Diese dann aber verschlüsselt und soweit ich informiert bin, ist RSA mit 4096 Bit im Moment noch nicht so einfach zu knacken. Ausserdem reduziert sich auf die Art die Datenmenge in der Datenbank und sorgt hoffentlich für gut Performance, auch wenn die Nutzerzahl steigt.
Man wird aber die Möglichkeit haben, auf dem heimischen Gerät den Chatverlauf zu speichern. Natürlich verschlüsselt. Wer das nicht will, der kann es ausschalten und wann auch immer er den Chat beendet, kann er nicht mehr auf den Verlauf zugreifen.
Schlussendlich werde ich im Moment den privaten Chat priorisieren. Das war eigentlich überhaupt nicht mein Plan, aber ich gehe davon aus, dass damit am schnellsten das Interesse für dieses kleine Netzwerk zu wecken ist.
In letzter Zeit werde ich immer wieder eine Sache gefragt:
SSH ist ja ein tolles Ding, aber kann man nicht verhindern, dass alles abbricht, wenn man die Verbindung beendet?
Die Antwort ist einfach, auch wenn ich hier einen anderen Weg zeige, als in den E-Mails. Sie lautet ja!
Wobei, ssh selbst wird immer alles hinter sich abbrechen, wenn die Verbindung beendet wird. Das ist aber gar nicht schlimm, denn es gibt kleine Helfer, mit denen man das trotzdem regeln kann.
Bislang habe ich immer Screen für diesen Fall genannt. Nun dachte ich, stelle ich das Ding hier doch einmal vor. Da ich Screen aber eigentlich nur mit seinem minimalsten Können benutze dachte ich, da lese ich mich mal tiefer ein und gebe hier ein bisschen mehr Informationen.
Tja, da bin ich dann über Tmux gestolpert, habe es mir angeschaut und mir persönlich gefällt es besser. Das ist aber alles irgendwo Geschmacksache, aber ich habe mich jetzt dafür entschieden, hier Tmux vorzustellen.
Zuerst muss Tmux installiert werden. Aber Achtung! Es muss dort installiert werden, wo es auch ausgeführt werden soll! Sprich, wenn ihr es auf einem Server betreiben wollt, dann muss es auf dem Server installiert werden!
Wie immer, ihr solltet wissen, wie man ein Programm bei eurer Distribution installiert. Unter Arch wäre es:
sudo pacman -S tmuxTmux ist aber auch auf dem heimischen Rechner von Vorteil. Also ohne das man vorher mit ssh auf einen anderen Rechner muss. Dabei unterscheidet sich nur eine Sache! Auf einem entfernten Rechner muss man sich erst zum Beispiel mit ssh verbinden, auf dem lokalen Gerät natürlich nicht. Alles Andere ist gleich!
Man startet Tmux über einen Terminal. Irgendwie logisch. Dazu reicht es schon, wenn man
tmuxeingibt. Ja, es reicht, aber es hat seine Vorteile, wenn man der Session einen Namen gibt. Das geht dann so:
tmux new -s <name>Warum das Sinn macht? Nun, wer sagt denn, dass man nur eine Session starten will? Vielleicht hat man ja mehrere laufen und wer ein wenig mit Tmux arbeitet, dem wird das wahrscheinlich auch passieren, denn Tmux eignet sich auch wunderschön, um etwas zu organisieren! Ihr werdet sehen!
tmux new -s tut
Ja schau an, so viel ist da ja gar nicht passiert, oder? Da unten ist so ein grüner Balken, aber was nun?
Ganz einfach. Tmux hat eine neue Session mit dem Namen tut gestartet und darin läuft, man glaubt es kaum, der bevorzugte Terminal! In meinem Fall eben Bash. Warum ich nicht zsh benutzte? Na ja, da hätten wir dann ein ganz anderes Thema!
Okay. Aber was bringt das jetzt? Ganz einfach. Alles, was da drin nun passiert, passiert auch weiterhin. Egal, ob man ssh, oder den lokalen Terminal einfach schliesst. Das zeug darin läuft weiter!
Um das zu verdeutlichen, starte ich htop, schliesse den Tab, öffne einen neuen und verbinde mich wieder mit der Session.
Das funktioniert immer, solange der entsprechende Rechner läuft. Bei einem Neustart hingegen wird auch Tmux und die Session beendet. Wer das aber auf einem Server einsetzt, dem sollte das wohl egal sein.
Das ist im Prinzip schon die ganze Magie hinter Tmux.
Hier sei aber mal klar gesagt, ich gehe nicht auf die ganze Funktionsvielfalt und die ganzen Konfigurationsmöglichkeiten ein. Dann müsste ich das alles binden lassen und als Buch verkaufen. Ausserdem bin ich durchaus der Meinung, Learning by doing ist die beste Art, sich wirklich mit etwas vertraut zu machen. Hier will ich nur grundlegende Dinge erklären, die man im Hausgebrauch wohl am ehesten verwendet.
Ganz wichtig hierbei ist der Umgang mit Tmux. Der wird eigentlich gar nicht mit der Mouse gesteuert, sondern man benutzt dafür Kommandos, die man mit Tastenkombinationen eingibt.
Wer keine extra Konfiguration angelegt hat (wer es doch hat, braucht den Artikel wahrscheinlich auch gar nicht), der kommt mit der Standardkonfiguration daher und in dieser ist eines dominiertend.
Strg+bGibt man diese Kombination ein weiss Tmux, aha, da kommt jetzt ein Kommando.
Strg+b dZum Beispiel wird benutzt, um Tmux wieder zu verlassen. Dabei sei zu beachten, hier gibt es nur ein Einziges +! Das heisst, man drückt die Tasten nicht gleichzeitig!
Warum ich das so deutlich schreibe? Weil ich selbst bei meinen ersten Gehversuchen daran hängengeblieben bin und das Internet Abhilfe schaffen musste. Wie ich dabei gesehen habe, viele stellen diese Frage und das ist Grund genug, es auch zu erklären!
Das kennt man aus den meisten Terminals und im Video hat man ja auch gesehen, dass ich Tabs verwendet habe. Tmux kann das auch.
Neuer Tab: Strg+b c
Hier haben wir also zwei Tabs. Tab 0 und Tab 1. Hinter Tab 1 ist dann noch ein * der anzeigt, in welchem Tab man sich gerade befindet.
Natürlich kann man auch zwischen den Tabs wechseln.
Vorheriger Tab: Strg+b p
Nächster Tab: Strg+b n
Man kann aber auch mit Strg+b <n> direkt in einen Tab springen. Dafür sind die Zahlen dann wieder gut!
Jetzt eine Ausnahmeerscheinung!
Tab schliessen: Strg+d
Ja genau, hier gibt man kein b ein!
Etwas, was ich persönlich unglaublich praktisch finde, ist das splitten von Tabs. Dann hat man also mehrere Terminals in einem Tab und hat alles im Blick!
Als Beispiel nehme ich meinen Server daher. Da drauf laufen zwei verschiedene Minetest-Server. Ich habe meinen Tab in Tmux also horizontal gesplittet, links läuft der erste Server, Rechts der Zweite. So sehe ich auf einen Blick, ob irgendetwas nicht stimmt und muss nicht erst Tabs wechseln!
Tab horizontal splitten: Strg+b %
Tab vertikal splitten: Strg+b “
Zwischen gesplitteten Tabs wechseln: Strg+b <Pfeiltaste>
Dabei kann man auch geteilte Tabs weiter unterteilen. Das kann man ziemlich exzessiv treiben, aber irgendwann wird es unübersichtlich.
Man kann auch eine Reihe von vordefinierten Unterteilungen auswählen.
Strg+b Leertaste
und schon hat man verschieden gesplittete Tabs. Durch mehrmaliges drücken kann man diese durchschauen und nutzt dann den, der einem am Besten gefällt. Ich bin mir sicher, in den Einstellungen kann man das auch selbst definieren, habe ich aber nicht versucht.
Wem das nun Lust gemacht hat, der kann mittels
Strg+b ?sich eine Liste der verfügbaren Shortcuts anzeigen lassen. Da Scrollt man mit Bild hoch und Bild runter durch.
Zum guten Schluss gibt es auch noch die Kommandozeile mittels
Strg+b :Auch damit kann man spielen. Einfach ausprobieren!
Tmux ist eine ganz hervorragende Möglichkeit, auf dem lokalen Rechner, oder einem entfernten Server, Prozesse am Leben zu erhalten, auch wenn die Verbindung geschlossen wurde. Tmux ist einfach zu bedienen, wenn man die Geschichte mit den Shortcuts mal verstanden hat und die Fülle an Funktionen ist beeindruckend! Dazu noch die Möglichkeiten der Konfiguration, Spielkinder werden daran genauso ihren Spass haben wie diejenigen, die einfach nur auf einem entfernten System Prozesse am laufen halten wollen.
Ja, es geht wirklich immer weiter!
Mit Version 0.4 ist nun die erste nutzbare Version fertig. Alle grundlegende Funktionen sind enthalten und funktionieren!
Im Hauptfenster ist die Dokumenten-Liste hinzugekommen. Hier handelt es sich wieder um eine Baum-Liste, da ich mir noch nicht sicher bin, ob ich vielleicht irgendwann die Möglichkeit einbauen möchte, alle referenzierten Dokumente im Baum anzeigen zu lassen. So weite bin ich aber noch nicht, steht also in den Sternen!
Es sind auch zwei neue Punkte in der Menüleiste hinzugekommen. Dokument und Hilfe.
Unter Hilfe finden sich zwei Einträge. Mittels Handbuch kann man sich das PDF des Handbuchs anzeigen lassen. Ich habe mich dafür entschieden, den vom System vorgegebene Betrachter zu wählen. Es ist also nicht möglich, in dU-DA selbst einen Betrachter auszuwählen! Auch habe ich mich gegen den Einbau eines eigenen PDF-Betrachters entschieden. Qt bietet zwar ein paar Möglichkeiten, doch leider war das alles nicht so schnell zu realisieren, wie ich mir das erhofft hatte.
Ich selbst verwende Atril zum betrachten von PDFs. Das dürfte aber Geschmackssache sein.
Hat man da Worte? Mit dem Menüpunkt Über erscheint ein kleines Fenster und zeigt die aktuelle Versionsnummer an. Ich bin erschüttert! Darüber hinaus, wenn man in der Kommandozeile
duda --versioneingibt, bekommt man ebenfalls die Versionsnummer angezeigt.
Spannender ist natürlich der Menüpunkt Dokument.
Man kann ein Dokument anlegen, bearbeiten und löschen.
Löschen sollte selbsterklärend sein. Es erscheint eine Sicherheitsabfrage, danach wird das Dokument vollständig aus der Datenbank entfernt.
Anlegen und bearbeiten wird über das Dokument-Fenster abgewickelt. Legt man ein neues Dokument an, so sind alle Felder leer, die Daten stehen auf 01.01.2021 und hinter ID steht “Wird zugewiesen!“. Die Datenbank vergibt die ID für neue Dokumente, weshalb hier nichts eingegeben werden kann.
Wird ein Dokument editiert, erscheinen hier die zuvor eingegebenen Daten mit Ausnahme der PDF-Datei. Bleibt dieses Feld beim ändern leer, wird auch an der PDF-Datei in der Datenbank nichts verändert. Wird hier ein neues PDF angegeben, wird jenes in der Datenbank dadurch ersetzt!
Bei Referenz kann man die ID eines anderen Dokuments einfügen, auf welches sich dieses Dokument bezieht. Hier muss eine Auswahlmöglichkeit her! So gefällt mir das noch nicht.
Nach dem speichern wird das neue Dokument mit neuer ID angelegt, oder ein bestehendes Dokument aktualisiert.
Derzeit führt ein Doppelklick auf ein gespeichertes Dokument dazu, dass die entsprechende PDF aus der Datenbank geladen und gespeichert wird, um sie anschliessend mit dem vom System vorgegebenen Betrachter anzuzeigen.
Hier, genau wie bei der Archiv-Liste, muss die Möglichkeit zur Sortierung eingefügt werden!
In dieser Version habe ich vor, sämtliche bei der Nutzung auftretende Unzulänglichkeiten zu beseitigen. Neue Funktionen werden keine eingebaut, es geht einzig darum, die Schwächen, welche bei der Entwicklung wenig auffallen, aufzuspüren und zu beseitigen. Dafür eignet sich meiner Meinung nach der laufende Betrieb am besten!
Git ist so eine kleine Wunderwaffe. Egal was man versionieren will, oder wenn man Backups erstellen möchte, oder ob man einfach mit mehreren Personen an etwas arbeiten will, Git ist einfach der Hammer! Klein, schnell, super funktionell und sehr einfach zu beherrschen!
Ich sage aber eines vorweg. Das hier wird nur eine kurze Schritt für Schritt Anleitung, wie man schnell und einfach mit Git arbeiten kann. Wer tiefer in die Materie eintauchen will, mit Erklärungen wie was funktioniert, dem empfehle ich dieses Werk. Da schlage ich auch immer wieder gerne nach!
Lassen wir mal die üblichen Beschreibungen weg und nennen das Kind beim Namen. Wenn man an einem Projekt arbeitet, welches verschiedene Versionen haben wird, denn bekommt man mit Git ein mächtiges Ding an die Hand.
Als Beispiel. Sagen wir mal, man entwickelt eine Software. Version 1.0 war toll, 1.1 hat auch gerockt, 1.2 konnte ebenfalls überzeugen, aber mit 1.3 hat man so richtig Mist gebaut. Da steckt auf einmal so viel Schrott drin, den man im Leben nicht mehr von Hand ausgebaut bekommt. Treibt man sein Programm dabei in seinem Arbeitsverzeichnis voran, bleibt man aber auf diesem Stand stehen. Entweder fängt man bei 0 an, versucht 1.3 dann doch irgendwie zu retten, oder macht sich dann echt die Mühe, alle Änderungen seit Version 1.2 von Hand rückgängig zu machen.
Hat man mit Git jedoch für seine Versionen eigene Branches angelegt, sieht die Welt mit einem Mal viel freundlicher aus. Version 1.3 ist also Murks und rückgängig machen ist auch nicht. Also geht man einfach in den Branch 1.2 und arbeitet damit weiter. Eine sehr bequeme Sache!
Auch forken, also ein eigentlich fremdes Projekt nach seinen Wünschen anpassen, geht damit hervorragend. Man clont sich einfach den Code, legt einen neuen Branch an und los geht es. Ohne das Original zu verändern!
Praktisch ist es aber auch, wenn man von bestimmten Dingen ein Backup erstellen möchte. Da sind Branches eher überflüssig, kann man aber definitiv auch verwenden.
Hat man seine Arbeit bis an den angestrebten Punkt voran getrieben, oder ist Backup-Tag, pusht man seine Arbeitskopie einfach auf den Server, oder wo auch immer man seine Gits liegen hat.
Das funktioniert auch beinahe wie eine Cloud. Sagen wir, normalerweise arbeitet man von seinem Desktop zuhause aus, pusht seine Änderungen nach getaner Arbeit und ist auf einmal irgendwo im Nirgendwo und hat Langeweile. Gut, da ist es dann natürlich praktisch, einen Laptop dabei zu haben.
Man clont sich einfach das Repository auf das Gerät, arbeitet, pusht anschliessend und pullt es zuhause wieder auf den Desktop. Einfach und bequem.
Viele werden das in Zusammenhang mit Git schon gehört haben. Da sich das jedoch eigentlich immer auf das programmieren bezieht, will ich mal ein anderes Beispiel hernehmen.
Sagen wir, da sind zwei Autoren, die am gleichen Buch arbeiten. Der Eine legt immer eine Szenerie in fünf Seiten grob vor, der Zweite arbeitet diese in den nächsten fünf Seiten weiter aus.
Autor 1 clont sich das Repository, schreibt seine fünf Seiten und pusht die im Anschluss zurück. Dann kommt Autor 2, pullt sich das Repository, schreibt wiederum seine fünf Seiten und pusht diese.
Am Ende ist das Buch fertig und vielleicht sitzen die Beiden dabei ewig viele Kilometer auseinander.
Zu installieren gibt es nicht viel. Man braucht eben Git. Oftmals ist das schon installiert, weil wirklich viele es einsetzen, aber falls nicht, muss man es eben doch hinzufügen.
sudo pacman -S gitSo sieht das bei Arch aus. Ich denke aber, wer sich schon an Git heranwagt, der weiss auch, wie man es installiert.
Man muss seine Repositorys nicht auf entfernten Rechnern auslagern. Das geht selbst verständlich auch lokal. Da ich aber davon ausgehe, dass die Meisten dann doch irgendwie gerne ihr Krempel extern auslagern, so können auch andere Beteiligen besser dran arbeiten, gehe ich auf eben diese Variante ein.
Wer es lokal machen will, der kann einfach den ssh Krempel weglassen.
Okay. Ziel der Übung wird es also sein, ein Repository auf meinem Raspberry anzulegen, es auf meinen Desktop zu klonen, etwas drin zu arbeiten und alles wieder auf den Raspberry zu schicken. Im Anschluss zeige ich dann noch das mit den Branches.
Da ich davon ausgehe, dass Nutzer, die nicht programmieren, es schwieriger haben werden, Programmcode zu verstehen, nehme ich einfach mal ein Beispiel, was nichts mit programmieren zu tun hat. Deshalb sage ich, wir wollen ein kleines Notizheft anlegen. Einfacher Klartext.
Git bietet eine ziemlich grosse Fülle an Einstellmöglichkeiten. So kann man beispielsweise auch einen bevorzugten Editor zum commiten angeben und ähnliches.
Wir wollen uns aber im Moment nur mit den wirklich notwendigen Dingen befassen.
Wer hätte es geahnt, wenn man mit verschiedenen Benutzern an einem Projekt arbeitet, würde man unter Umständen gerne wissen, wer wann welche Änderung vorgenommen hat. Da Git kein Hellseher ist, muss man ihm diese Informationen auch mitteilen.
git config --global user.name "John Doe"
git config --global user.email johndoe@example.comPeng. Das reicht schon. Einfach in den Terminal tippen, fertig. Natürlich sollte man anstatt “John Doe” und johndoe@example.com mit seinen eigenen Daten verwenden. Ja, hier kann man auch irgendwas eintragen. Wichtig ist eben, dass user.name und user.email in der Konfiguration vorhanden ist.
Da ich euch die Möglichkeit noch zeigen möchte, wie man commits mit einem Editor durchführt, sollten wir dieser Einstellung auch noch treffen.
git config --global core.editor nanoIch wähle deshalb nano, da der normalerweise eh installiert ist und sehr einfach bedient werden kann.
Zudem sollte man noch das Verhalten beim pullen einstellen. Sprich, was passieren soll, wenn etwas aus dem Repository entnommen wird.
git config --global pull.rebase falseFertig!
Es macht natürlich Sinn, dass Repository direkt dort anzulegen, von wo man es hinterher clonen will. Zumindest mache ich das immer so. Auch macht es Sinn, einen eigenen Ordner für die Repositorys anzulegen. Muss man nicht, dient aber der Übersichtlichkeit.
Ich für meinen Teil habe dafür einen Ordner mit dem bezeichnenden Ordner git. Ja, ich bin schon sehr einfallsreich. Der liegt in meinem Home-Verzeichnis auf dem Raspberr und wartet auf seinen Einsatz. Da gehe ich jetzt rein.
Also. Da soll jetzt das Repository notizen angelegt werden.
Erster Schritt, hinsetzen! Ja, ja, irgendwann wird das Geheimnis hinter diesem Schritt gelöst.
Als Nächstes wird ein neues Verzeichnis angelegt, was sinnvoller Weise den Namen des Repositorys haben sollte.
mkdir notizenWer hier jetzt dankbar ist, dass ich diesen Schritt beschrieben habe, der sollte sich vielleicht zuerst einmal doch näher mit Linux beschäftigen.
Gut. In das Verzeichnis gehen wir nun rein und dort heisst es dann
git init
Die Hinweise sind tatsächlich nur Hinweise. Wir ignorieren die jetzt einfach. Wer sich damit näher beschäftigen will, siehe meinen Link am Anfang des Artikels.
Leeres Git-Repository in /home/diabolus/git/notizen/.git/ initialisiert
Warum erzählt der denn jetzt sowas? Ganz einfach. Man ist nicht darauf beschränkt, ein neues Repository in einem leeren Verzeichnis zu erstellen. Wer schon ein Arbeitsverzeichnis hat, was er nun gerne über Git verwalten würde, der kann auch direkt darin auf dem gleichen Weg ein Repository erstellen.
Seit ich jedoch mit Git arbeite, ist der erste Schritt bei allen Projekten immer das erstellen des Repositorys und, oh wunder, da ist das Verzeichnis dann eben leer.
Damit sind wir aber noch nicht ganz fertig, denn ein ganzes, reales Verzeichnis clont sich in meinen Augen ziemlich schlecht. Man sieht ja auch zum Beispiel auf Github, alles was man clont, ist eine Datei mit der Endung .git. Genau eine solche wollen wir auch!
Also wieder raus aus dem Verzeichnis und dann:
git clone --bare notizen
warning: Sie scheinen ein leeres Repository geklont zu haben.
Warum diese Meldung als Warnung gekennzeichnet ist, erschliesst sich mir nicht wirklich. Ich habe noch nie einen negativen Effekt gefunden, der auf ein leeres Repository zurückzuführen gewesen wäre. Einzig kann ich mir vorstellen, dass die Warnung ein Hinweis sein soll, um eventuell auf ein falsch angegebenes Verzeichnis hinzuweisen.
Schau an, da haben wir ja die Datei notizen.git, die wir nun ganz bequem clonen können.
Ich für meinen Teil lösche im Anschluss immer das Verzeichnis. Ist ja ohnehin leer und darin wird auch nicht mehr viel passieren. Wer jedoch ein bereits gefülltes Verzeichnis benutzt hat, will diesen Schritt wahrscheinlich gerne überspringen. Ist kein Problem! Einfach Verzeichnis bestehen lassen und gut ist.
Da gibt es sehr viele Wege. Der Einfachste, für den man nicht noch gross was installieren und einrichten muss, ist ssh. Ich persönlich arbeite an meinen Projekten alleine, deshalb reicht es, wenn ich meinen Benutzer dafür verwende. Wer jedoch in einem Team arbeiten will, der sollte einen eigenen Benutzer für Git anlegen, dessen Zugangsdaten auch die Teammitglieder bekommen.
Wie man nun aber einen Benutzer anlegt, die Rechte vergibt und das alles, soll hier nicht Bestandteil das Artikels sein. Dafür gibt es schon X-Anleitungen im Netz und eigentlich hat jedes Linux irgendwo in seiner Anleitung diesen Schritt ebenfalls gut beschrieben drin.
Für diesen Artikel reicht es aber auch, wenn man mit seinem Benutzer den fernen Computer erreichen kann.
Auf dem Arbeitscomputer, in dem Verzeichnis seiner Wahl, kann man nun das Repository clonen. Dabei wird automatisch das entsprechende Verzeichnis angelegt! Würde man nun ein Verzeichnis notizen erstellen und dort drin das clonen durchführen, hätte man wieder ein Verzeichnis namens notizen. Ist also unsinnig.
git clone <benutzername>@<adresse>:/home/<benutzername>/git/notizen.gitNatürlich muss man <benutzername> und <adresse> mit seinen jeweiligen Daten ersetzen. In meinem Fall wäre das also:
git clone diabolus@piserver:/home/diabolus/git/notizen.git
Das hat ja hervorragend funktioniert! Natürlich wird man gebeten, dass Passwort einzugeben. Wäre ja auch zu schön, wenn da einfach jeder mal was clonen könnte.
Wer kein Passwort eingeben will, der kann hier auch Schlüssel generieren und die öffentlichen Schlüssel den jeweiligen Systemen bekannt machen. Darauf gehe ich hier aber nicht ein.
Ja, wie arbeitet man nun damit? Ganz einfach! Genau so, wie man sonst auch arbeiten würde. Git ist es herzlich egal, mit welcher Software man hier was erstellt. Das spielt überhaupt keine Rolle.
Für unser Notizbuch reicht ein einfacher Editor. Egal ob grafisch, oder im Terminal. Spielt keine Rolle. Wichtig ist jedoch logischerweise, die Dateien müssen auch im Verzeichnis notizen liegen! Ich verwende einfach Nano und lege nun die Datei notiz.txt an.
nano notiz.txtDa schreibe ich jetzt etwas rein.
Das ist also der kleine Text, den ich in die Notiz geschrieben habe. Eben eine ganz einfache Text-Datei. Juckt Git alles nicht. Das frisst, was man ihm vorwirft.
Nun war das genug Notizen für heute. Ich will das so jetzt auch auf dem Server haben.
Das muss man Git dann auch sagen! Denn derzeit hat Git noch überhaupt keine Ahnung, was es mit dem komischen Text auf sich hat. Auf welchem Stand Git gerade ist, kann man so abfragen:
git status
Aha. Git hat also festgestellt, dass sich im Verzeichnis etwas geändert hat. Aber wir sind hier der Meister und nicht Git! Von daher übernimmt Git nicht automatisch alles, was man ihm so vorwirft. Wir müssen ihm sagen, was mit den Dateien, die Git bislang nicht kennt, oder die verändert wurden, passieren soll.
git add *Damit sagen wir Git, dass es alle Dateien übernehmen soll.
Ist das nicht nett von Git? Es sagt dazu einfach gar nichts. Hat es denn nun getan, was man von ihm verlangt hat? Fragen wir doch einfach wieder den Status ab.
Ausgezeichnet! Es gibt also Änderungen im Verzeichnis, die Git verwalten soll. Aber, wie ich ja gerade geschrieben hat, es hat sich etwas verändert! Um die Änderungen jetzt aber offiziell an Git zu übergeben, also zu commiten, müssen wir noch etwas tun. Eben es commiten! Dabei sollte man dann gleich noch eine gute Beschreibung hinzufügen, um es später besser nachvollziehen zu können.
git commit -m "Erster Eintrag in der Datei notiz.txt"
Ausgezeichnet! Damit sind wir mit der Arbeit auch schon fertig!
Tatsächlich hat sich aber alles auf dem lokalen Computer abgespielt. Würde ein anderer Benutzer jetzt das Repository clonen, wäre von den Änderungen noch nichts zu sehen!
Das ist jedoch kein Bug, sondern ein Feature! Sagen wir, ein Autor ist mit seiner Arbeit noch nicht fertig, hat an dem Tag aber keine Lust mehr, noch etwas zu schreiben. Dann führt der seine Arbeit am nächsten Tag fort. Dennoch kann er die bisherigen Änderungen commiten. Vielleicht, um irgendwann einmal darauf zurückkommen zu können. Oder ein Programmierer hat die eigentliche Programmierung abgeschlossen, will aber alles erst einen Tag später noch sorgfältig testen, wenn er frisch und ausgeruht ist. Deshalb ist das veröffentlichen des Repository absichtlich eine manuelle Geschichte.
Das veröffentlichen ist aber sehr einfach. Wobei das Wort veröffentlichen hier vielleicht zu Missverständnissen führt. Natürlich veröffentlicht man seine Arbeit nicht sofort. Man aktualisiert quasi nur das Repository auf dem Server. Deshalb heisst es auch eigentlich push und nicht veröffentlichen.
git pushMagie, oder? Da ist es wirklich von Vorteil, dass wir alle in unserer Kindheit Raketenwissenschaft und Astronavigation studiert haben!
So. Da ist dann jetzt aber noch einer im Boot, der ebenfalls gerne mit dem Notizbuch arbeiten will. Ich simuliere das einfach mit meinem NetBook genannt Mini-Horst.
Was man dabei zuerst tut, sollte klar sein. Man setzt sich hin! Danach clont sich Mini-Horst das Repository, wie oben beschrieben. Er möchte eigene Notizen anlegen, aber liest auch die Notiz von Horst, sprich meinem Desktop. Da Mini-Horst ein gar lustiges Kerlchen ist, will er da einen Kommentar hinzufügen und editiert einfach mit dem Editor seiner Wahl die Datei notiz.txt.
Ach, er ist so nett, der Mini-Horst.
Gut. Nun will Mini-Horst aber eine weitere Notiz für sich erstellen und erstellt dafür die Datei notiz2.txt.
Ja! Cola ist wichtig!
Was sagt denn aber Git nun, wenn man den Status abfragt?
Genau! Git erkennt, dass die Datei notiz.txt geändert wurde und da noch eine neue Datei vorhanden ist, die es noch gar nicht kennt. Auch Mini-Horst muss seine Änderungen also adden, commiten und dann pushen.
Nun kommt wieder Horst, als mein Desktop. Vor der Arbeit will er checken, ob sich im Repository etwas getan hat. Das geht dann ganz einfach mit:
git pullAlso push (schieben), um etwas ins Repository zu bringen und pull (ziehen), um es zu aktualisieren.
Ach schau an, da ist ja was neues drin!
Git erkennt, wenn sich nichts geändert hat und meldet dann:
Bereits aktuell!Horst würde nun gerne wissen, was sich da geändert hat. Okay, bei zwei einfachen Textdateien kann man sich das noch schnell mal anschauen, bei grösseren Projekten kann das aber schnell unübersichtlich werden.
Aber war da nicht was mit commit? Musste man da nicht vor dem pushen was eingeben? Dann könnte man doch da mal nachschauen, was so passiert ist!
Richtung! Deshalb sollte man beim commiten auch wirklich hinschreiben, was man geändert hat. Das erhöht die Nachvollziehbarkeit.
Und wie macht man das jetzt? So:
git log
Na ist das nicht schön? Alle wichtigen Informationen sind da. Wer hat da was geändert, wann und was. Letzteres zumindest dann, wenn das jeweilige Team-Mitglied seinen Job auch ernst nimmt.
Aha. Der hat also die Notiz kommentiert. Schauen wir uns das doch einfach mal an!
Was ein Klugscheisser! Aber, was hat er denn da notiert?
Oh Cola! Muss ich gleich mal in der Garage schauen, ob ich noch genug habe!
Ich denke mal, damit sollte das arbeiten in einem Team mit git verständlich sein.
Gut. Die Beiden arbeiten also mit den Notizen und finden das ganz toll. Was aber, wenn da jetzt eine neue Notiz auftaucht, die Horst für Mini-Horst hinterlegt hat? Klar, Horst hat das natürlich brav beschrieben und Mini-Horst sieht im Log, dass eine Notiz extra für ihn erstellt wurde.
Nun kommt Mini-Horst aber auf eine Idee! Er will das Format der Notiz etwas ändern, damit aus dem Inhalt schon ersichtlich ist, um was es eigentlich geht.
Er könnte jetzt einfach eine neue Notiz erstellen, wo er das neue Format einfügt. Das würde er dann pushen und Horst bitten, sich das anzuschauen. Oder er editiert direkt die Notiz von Horst. Wäre auch möglich.
Beides hat aber eine Nachteil. In beidem Fall wird das eigentliche Projekt “zugemüllt”. Entweder erscheint da eine neue Notiz, oder Horst hat etwas in seiner Notiz stehen und findet das gar nicht gut. Wäre doch schön, wenn man Änderungen vornehmen könnte, ohne dabei das Original zu verkratzen!
Hier kommen Branches ins Spiel. Also Zweige, die vom Baum abgehen. Mini-Horst erstellt also zuerst mal einen neuen Branch mit dem Namen format.
git branch format
Mit:
git branchkann man sich alle Branches anzeigen lassen. Jenes mit dem * ist das, in welchem man sich gerade befindet. Mini-Horst will nun in den neuen Branch wechseln.
git checkout format
Er ist also jetzt in einem neuen Zweig des Projektes. Mal schauen, ob sich im Ordner was verändert hat.
Nö. Alles so, wie man es erwarten würde!
Mini-Horst editiert jetzt die Datei notiz3.txt und baut dort seinen Vorschlag für ein neues Format ein.
So gefällt ihm das. Das muss nun kommentiert und gepusht werden.
Hier geht das pushen jedoch ein wenig anders. Der Grund dafür ist simpel. Nur weil man da an etwas herumspielt, muss das ja nicht gleich für jeden relevant, oder interessant sein. Unter Umständen tut man da etwas, nur um was herauszufinden, etwas zu versuchen usw. Deshalb muss man einen Branch auch extra pullen.
git pull origin formatNun kommt Horst daher, pullt alles und schreibt schnell was in die Datei notiz.txt, ohne sich um die Änderungen im Repository zu kümmern. Was heisst er kümmert sich nicht um die Änderungen? Er bekommt ja gar keine angezeigt! Das heisst, er bekommt trotz pull nichts von dem neuen Branch mit.
Das merkt dann auch Mini-Horst und will Horst trotzdem mitteilen, dass es da eine Änderung gibt. Also schreibt er es in die Datei notiz4.txt. Aber wieder unter dem Branch master, nicht unter format. Commiten, pushen und abwarten.
Horst pullt wieder und ihm fallen Änderungen auf. Er schaut in die Logs.
Hier fällt nun etwas auf. Die Ausgabe ist länger, als der Terminal hoch ist. Deshalb erscheinen unten die Doppelpunkte. Drückt man Enter, geht es nach unten weiter. Das kennt man aber wahrscheinlich schon und drückt deshalb einfach q.
Aha. Mini-Horst hat also einen Formatforschlag gemacht im Branch format. Schauen wir uns das doch einmal an.
Öhm. Es gibt aber gar keinen Branch namens format. Dann muss Horst den wohl manuell abholen.
git fetch origin format
Das hat ja geklappt. Dann muss der Branch ja jetzt da sein.
Mysteriös. Er ist nicht da! Was passiert denn aber, wenn man einfach in den Branch wechselt? Angeblich ist er ja heruntergeladen worden.
Ach ne. Da ist er ja! Ausserdem hat Git uns auch gleich in den Branch gewechselt. Interessant! Dann schauen wir doch mal, was Mini-Horst da vorgeschlagen hat!
Ah! Von, An, ja, sieht übersichtlicher aus. Machen wir so! Aber, ist das jetzt schon direkt so auch in der Datei notiz3.txt in master?
Nein! Das heisst, hätte Mini-Horst jetzt da irgendeinen unsinnigen Schwachsinn eingebaut, hätte man den Branch einfach löschen können und nichts weiter wäre passiert.
Aber gut. Was Mini-Horst da gemacht hat, was gut und ist sinnvoll. Aber muss Horst das jetzt in der Datei notiz3.txt so abtippen? Natürlich nicht!
Man kann ganz einfach die Änderungen übernehmen. Dazu muss man sich im Branch master befinden.
git merge format
Ach da schau her! Automatisch wird der eingangs ausgewählte Editor gestartet und man wird aufgefordert, den Grund für das Zusammenführen (merge) zu beschreiben. Prima, macht Horst doch gerne!
Nachdem die Beschreibung gespeichert wurde und der Editor wieder zu ist, werden die Änderungen übernommen. Aber Vertrauen ist gut, Kontrolle ist besser. Also schauen wir zuerst, ob wir im Branch master sind und ob die Datei notiz3.txt nun auch wirklich die Änderungen übernommen hat.
Jawohl, hat hervorragend funktioniert! Das kann man jetzt pushen und fertig.
Ich arbeite noch nicht so lange mit Branches. Es liegt deshalb im Bereich des Möglichen, dass man damit auch einfacher arbeiten kann. Sollte ich dafür einen Weg finden, dann werde ich das hier aktualisieren.
Falls mich dabei aber jemand unterstützen kann, eine Mail würde mich freuen.
Git kann einem die Arbeit wirklich erleichtern. Es macht genau das was es soll und man muss sich an keine Restriktionen halten. Ich habe mir schon Videos zu anderen Versionierungssysteme angeschaut und hab mich jedes Mal gefragt, warum man das einsetzen sollte. Da werden unter Umständen die Arbeitsweisen vorgegeben, jeder Branch ist gleich ein komplettes Verzeichnis mit allen Dateien, was bei grossen Projekten Zeit und Speicherplatz kostet, oder man bekommt direkt eine komplette Umgebung vorgesetzt, wo man nur mit den jeweiligen, vorgeschriebenen Tools arbeiten kann.
Git macht nichts davon. Eigentlich merkt man gar nicht, dass Git da ist, solange man nicht pullt, pusht, oder commitet. Das ist auch gut so. Es tritt nur dann in Erscheinung, wenn man es braucht und wenn man selbst entschieden hat, dass man es nun einsetzen will.
Und es geht weiter! Das Projekt ist schon so jung und dennoch gibt es deutliche Veränderungen zur Version 0.2.
Das Passwort ist aus den Einstellungen geflogen. Da PostgreSQL die Übertragung eines Passwort in “Plain Text” verlangt, wäre die Verschlüssung auf Seiten des Clients lediglich für die Konfiguration notwendig. Diesen Aufwand wollte ich dafür jedoch nicht betreiben. Vielleicht in einer späteren Version.
Aus diesem Grund habe ich mich dafür entschieden, dass man das Passwort zum Programmstart eingeben muss. Das wird dann intern gespeichert und über die ganze Sitzung verwendet. Findet das Programm jedoch keine gültige Konfigurationsdatei, zum Beispiel beim ersten Programmstart, erfolgt diese Abfrage nicht und beim Start wird auch keine Abfrage an die Datenbank geschickt. Nachdem die Konfiguration korrekt ausgefüllt wurde, kann über den Menüpunkt Datenbank->Abrufen manuell ein Abfrage losgeschickt werden. Diese fragt dann erneut nach dem Passwort, solange noch keines gesetzt wurde.
Darüber hinaus ist es nun auch möglich, Archive anzulegen, diese umzubenennen und auch wieder zu löschen.
Im Hauptfenster werden alle angelegten Archive in einer Baumliste angezeigt. Das hat derzeit noch keinen wirklichen Nutzen, doch für spätere Versionen will ich mir diese Möglichkeit einfach offen halten.
Eine Sortierung der Liste nehme ich auch in einer späteren Version vor.
Schlussendlich habe ich auch ein Handbuch in HTML und PDF erstellt. Dieses wird mit jeder neuen Version kontinuierlich mitwachsen.
In der nächsten Version werde ich das einfügen, bearbeiten, anzeigen und löschen der Dokumente in Angriff nehmen. Dafür wird es eine neue Liste neben der Archiv-Liste geben.
Zu den eigentlichen PDFs wird es auch die Möglichkeit geben, dass Datum des Dokuments zu speichern, es wird automatisch gespeichert, wann das Dokument in die Datenbank eingefügt wurde, man kann dem Dokument ein Kommentar hinzufügen und eine Referenz zu einem anderen, gespeicherten Dokument anlegen.
Mit dem letzten Punkt hoffe ich, einen Schriftverkehr nachvollziehbar zu machen. Je nach Möglichkeiten soll man alle zum Dokument gehörigen PDFs, möglichst nach Datum sortiert, gleichzeitig anzeigen können.
Hinzukommen wird auch eine Auswahlmöglichkeit für PDF-Betrachter in den Einstellungen. Ich spiele jedoch auch mit dem Gedanken, einen eigenen PDF-Betrachter direkt ins Programm einzubauen. Das steht jedoch noch nicht fest. Unter Umständen arbeite ich auch zuerst mit einem externen Programm.
Das Netzwerk ist ja schon eine tolle Sache. Rein theoretisch kann man von überall auf seinen Computer zugreifen, Daten entnehmen, an Projekten arbeiten, Wartung durchführen, oder was auch immer. Die Möglichkeiten scheinen schier endlos!
Was aber, wenn man von aussen gar keinen Zugriff auf den heimischen Rechner bekommt, da der Router das nicht zulassen will?
Einige werden schon vor dem Problem gestanden haben! Da bin ich mir ziemlich sicher!
Lösungswege gibt es da viele. So kann man zum Beispiel, wenn man mit Git arbeitet, einfach auf einem externen Server seine Projekte auslagern und greift dann dort zu. Das funktioniert ausgezeichnet und ich mache das genauso.
Nächste Möglichkeit, wenn man ja schon einen Server zur Hand hat, man baut sich ein VPN auf. Auch das habe ich bei mir so realisiert. Funktioniert ebenfalls ganz ausgezeichnet!
So. Nun ist man aber bei Kollege XYZ und auf einmal steht man vor einer Aufgabe. Sagen wir mal, der will mittels Qemu eine virtuelle Maschine in Betrieb nehmen, aber irgendwie will das einfach nicht funktionieren. Man selbst weiss aber, zuhause hat man sich schon ein Start-Skript gebastelt, welches hervorragend funktioniert. Das Problem ist nur, dass ist eben zuhause und nicht hier. Dummerweise ist Kollege XYZ nicht im eigenen VPN und das ist auch gut so. Vielleicht hat man zuhause ja zum Beispiel Bilder gespeichert, welche jene Person nicht sehen soll? Ergo, der soll nicht ins VPN.
Wie toll wäre es denn, wenn man trotzdem eine Möglichkeit hätte, auf den heimischen Rechner zuzugreifen?
Genau hier setzen wir an. Ziel der Mission ist es, einen heischen VNC über das Internet zugänglich zu machen. Ohne VPN! Ich habe mich dabei bewusst für VNC entschieden und nicht für SSH, da man damit dann noch andere Spielchen machen kann. Ihr werdet sehen!
Ich will versuchen, den VNC auf meinem Raspberry Pi über meinen Laptop zu erreichen. Den Laptop nehme ich dabei aus dem heimischen Netz und lasse ihn mittels Hotspot über mein Handy eine Verbindung aufbauen.
Ziel soll es sein, den VNC über eine Domain zu erreichen. Also zum Beispiel raspi.tld:5901. Ihr werdet verstehen, warum ich hier nicht die wirkliche Adresse angebe.
Wie man einen VNC installiert und einrichtet, habe ich schon im Artikel TigerVNC (ab 1.11.0) beschrieben, da gehe ich also nicht mehr drauf ein.
Hier soll es einzig darum gehen, wie man den entsprechenden Tunnel aufbauen muss. Dazu installiert man … na ja … Linux. In allen mir geläufigen Distributionen ist von Start an alles dabei, was man dafür braucht. Ergo, installieren muss man hier nichts!
Der Pi stellt mir dabei ein Bein. Natürlich. Bei dem war autossh nicht installiert, was ich erst beim schreiben dieses Artikels gemerkt habe.. Das geht aber simpel mit:
sudo pacman -S autosshZumindest unter Arch. Wie ihr das in eurer Distribution, falls es doch nicht vorhanden sein sollte, installiert, dürftet ihr ja selbst wissen.
Auf dem Pi und meinem Laptop läuft jeweils Arch, auf dem Server Gentoo.
Versteift euch jetzt nicht darauf, dass ich hier mit einem Raspberry arbeite. Für mich bietet sich das im Moment aus Gründen einfach an. Ihr könnte das natürlich auf jedem in eurem Netzwerk befindlichen, Linux betriebenem Rechner machen!
Da haben wir ihn auch schon. Im linken Terminal werde ich alle Arbeiten am Raspberry Pi durchführen, der bei mir piserver heisst, da ich recht viel mit dem kleinen Kerl mache. Im rechten Terminal arbeite ich dann auf dem Server.
Ja, ich weiss. Kaum einer wird vor der Arbeit dumm vor seinem PC stehen. Warum ich das trotzdem immer wieder schreibe, werde ich irgendwann einmal enthüllen!
Dieser Schritt ist optional. Wer das nicht durchführen will, der muss eben jedes Mal das Passwort eingeben. Hier geht es also wirklich nur darum, dem Server den Pi bekannt zu machen, damit der Server weiss, den da kenne ich, der darf rein.
Wer natürlich schon seinen heimischen Rechner mittels Keys dem Server bekannt gemacht hat, der kann diesen Schritt ebenfalls überspringen. Aber, wem sag ich das?
Wir wollen natürlich nicht irgendeinen dahergelaufenen Schlüssel. Der soll schon was bringen, also darf er auf RSA basieren und 4096 Bit haben. Soll ja nicht irgendwer da unerlaubt einbrechen können.
Das funktioniert sehr einfach.
ssh-keygen -t rsa -b 4096
Das war ja schon erfreulich einfach. Man wird nach einem Zielverzeichnis gefragt, nach einem Passwort und der Passwort Wiederholung. Das kann man einfach alles mit Enter durchreichen.
Schockierend aber wahr, dass war es schon auf dem Pi. Ergo, wer seinen Schlüssel schon generiert und an den Server geschickt hat, der muss auf dem Rechner zuhause gar nichts machen! Oder auch jene, die lieber ein Passwort eingeben. Auch die haben auf dem heimischen Rechner keine Arbeit!
Siehe oben.
Von Werk aus will SSH aber nicht zulassen, was wir da vorhaben. Grund dafür sind Sicherheitsaspekte. Keine Tür öffnen, die man eigentlich nicht braucht.
So, wir wollen das aber jetzt haben, also müssen wir folgende Datei als Root editieren:
sudo nano /etc/ssh/sshd_config
Hier müssen nun folgende drei Zeilen auskommentiert werden. Bei Bedarf kann man sie auch einfach kopieren und ganz unten hinzufügen.
#GatewayPorts no
wird zu
GatewayPorts yes#ClientAliveInterval 0
wird zu
ClientAliveInterval 60#ClientAliveCountMax 3
wird zu
ClientAliveCountMax 2Oder eben für die Faulen:
GatewayPorts yes
ClientAliveInterval 60
ClientAliveCountMax 2Einfach ans Ende kopieren.
Das wird dann gespeichert.
Ich denke zwar, die Meisten werden das ohnehin gleich getan haben, aber wer es vielleicht nicht wissen sollte, nachdem man an der sshd_config etwas verändert hat, sind diese Änderungen erst nach einem Neustart von sshd wirksam. Das ist aber glücklicherweise sehr einfach.
sudo systemctl restart sshdJetzt kann man sich noch anschauen, dass man auch keinen Mist gemacht hat und sshd auch wieder sauber läuft.
sudo systemctl status sshd
Japp, läuft alles!
In diesem Schritt dürfte klar werden, warum ein solches Layout der beiden Terminals ein Vorteil ist.
Man könnte nun auf diverse Wege den Key auf den Server schicken. Über sshfs, über die Kopierfunktion von ssh, über FTP, was weiss ich. Es geht aber auch viel einfacher!
Der öffentliche Schlüssel ist nichts weiter als eine Ansammlung von Zeichen. Schauen wir es uns doch einfach mal auf dem Pi an.
cat .ssh/id_rsa.pub
Das ist tatsächlich alles! Verwechselt das aber bitte nicht mit eurem privaten Schlüssel, der bleibt mal schön geheim! Den Text markieren wir jetzt und kopieren ihn in die Zwischenablage. Strg+c funktioniert in den Meisten Terminal-Emulatoren nicht, da muss man also mit der rechten Mousetaste ans Werk.
Hat man das, öffnet man einfach, zum Beispiel mit Nano, auf dem Server die notwendige Datei:
nano .ssh/authorized_keysHier kopiert man dann einfach die Zwischenablage wieder ein.
Noch speichern und man ist fertig! Geht eigentlich wirklich sehr einfach und schnell.
Gerade, wenn man alles zum ersten Mal konfiguriert, empfiehlt es sich, dem Server ein bisschen auf die Finger zu schauen. Klappt denn alles, was man da so gemacht hat? Wird der richtige Port geöffnet? Wird überhaupt ein Port geöffnet?
Ich empfehle deshalb folgendes auf dem Server auszuführen:
watch "netstat -tulpn"
Das sieht dann so aus. Verzeiht, wenn ich einige Teile unkenntlich gemacht habe. Man weiss ja nie, wer aus welcher Information etwas negatives extrahieren kann.
Aber gut, wenn das läuft, können wir den Tunnel ja mal vom Pi aus aufbauen.
ssh -N -R 5901:localhost:5901 diabolus@raspi.tldWas genau macht das jetzt? Wichtig ist die Option -R, da die für den Tunnel zuständig ist.
Die nächste, wichtige Option ist 5901:localhost:5901. Damit sagen wir dem Server, er soll den Port 5901 auf der Rechten Seite bei sich auf den Port 5901 vom Pi mappen. Hier könnte man auch schreiben:
5901:localhost:6789Dann müsste man mit dem VNC auf Port 6789 gehen und käme dennoch auf dem Port 5901 vom Pi raus. Das kann ja recht praktisch sein!
Der letzte Parameter diabolus@raspi.tld ist der normale Zugang zum Server. So wie ihr normalerweise auch auf den Server gelangt. Hab ihr auf dem PC zuhause und dem Server den gleichen Benutzer, könnt ihr den auch weglassen. Also dann einfach nur raspi.tld.
Feuern wir das mal ab und schauen, was passiert!
Tada, da ist ja unser Tunnel! Hat soweit also alles funktioniert. Oder? Finden wir es doch heraus!
Auf dem Laptop gebe ich jetzt einfach folgendes ein. Der ist über den Hotspot meines Handys verbunden und hängt nicht im heimischen Netz!
vncviewer raspi.tld:5901
Freude schöner Götterfunke …
Hat ja super geklappt! Ich kann nun also von Aussen mühelos auf meinen VNC vom Pi zugreifen, damit arbeiten usw. Ohne, dass auf dem fernen Rechner mehr installiert ist, als nur ein VNC-Viewer! Kein VPN, kein gar nichts!
Okay. Man könnte jetzt hier kritisch anführen:
Und wenn auf dem entfernten Rechner kein VNC ist?
Das ist natürlich richtig. Aber, man kann es ja nicht nur mit VNC machen! Vielleicht arbeitet man ja an einem streng geheimen Projekt, dessen Daten nicht auf irgendeiner Festplatte auf irgendeinem Host-Anbieter liegt!
Vielleicht ist man ja ein Autor, so wie ich, und hat seinen neusten Bestseller auf einem Gitlab zuhause liegen und will es nun einem guten Freund zur Korrektur übergeben. Ja, man könnte es auch ausdrucken, auf Stick ziehen, oder was auch immer. Denkt mir nicht immer alles kaputt, sondern überlegt euch selbst Szenarien!
Ausserdem sind wir ja noch gar nicht fertig!
Schauen wir uns doch noch einmal diesen Screenshot an:
Einem geübten Anwender dürfte dabei etwas beim Pi auffallen.
Richtig! Der hängt in seinem Kommando fest! Schliessen wir das Terminal, verschwindet auch der Tunnel und das wollen wir ja wahrscheinlich nicht!
Die Lösung hier heisst autossh. Im Prinzip ganz einfach ssh, mit ein paar Zusatzoptionen. Starten wir den Tunnel doch mal mit folgendem Kommando:
autossh -M 0 -f -o ConnectTimeout=10 -o ServerAliveInterval=60 -o ServerAliveCountMax=2 -N -R 5901:localhost:5901 diabolus@raspi.tld
Ja da schau her! Der Tunnel ist da und trotzdem könnte man jetzt die Verbindung zum Pi beenden, ohne dass der Tunnel verloren geht. Total toll!
Btw. Auf dem Pi musste ich autossh tatsächlich nachinstallieren. Auf meinem Desktop war es direkt dabei. Komisch. Also falls jemand autossh nicht drauf haben sollte, einfach nachinstallieren.
Nun gut. Soweit ist das ja alles schon ganz toll! Es hat aber einen kleinen Schönheitsfehler. Der Tunnel ist weg, wenn der Pi neu gestartet wird. Das kommt bei mir zwar nur selten vor, da der immer läuft, aber da ist ja noch die Geschichte mit den Updates. Ist da ein neuer Kernel dabei, soll der ja auch benutzt werden, was dann doch ein Neustart erfordert.
Der umständliche Weg wäre, man könnte autossh dann nach dem Neustart ausführen. Geht, ist auch in Ordnung. Aber hier schlägt der böse Murphy mit seinem dummen Gesetz wieder zu. Es kann also sein, dass man 1000x ein Update durchführt und jedes Mal brav autossh wieder gestartet hat. Dann kommt dieser eine Fall, wo man es vergisst, unterwegs ist und der Tunnel ist weg, obwohl man ihn gerade da brauchen würde.
Um das zu umgehen, habe ich ein bisschen rum gebastelt. Es gibt sicherlich einige Wege, wie man das lösen kann, ich bevorzuge jedoch, wenn alles schön einheitlich ist. Was würde da also näher liegen, als einen Service für den Tunnel bereitzustellen?
Damit das nicht jeder selber bauen muss, habe ich hier mal etwas zum kopieren und einfügen für euch.
[Unit]
Description=einen Tunnel für VNC
After=network-online.target
Wants=network-online.target
[Service]
Environment="LC_ALL=C.UTF-8"
Environment="LANG=C.UTF-8"
Type=simple
User=<benutzer>
ExecStart=/usr/bin/autossh -M 0 -o "ConnectTimeout=10" -o "ServerAliveInterval=60" -o "ServerAliveCountMax=2" -N -R 5901:localhost:5901 <benutzer>@<server>
[Install]
WantedBy=multi-user.target
So einfach kommt ihr mir aber nicht damit durch! Denn überall wo <benutzer> und <server> steht, müsst ihr natürlich eure Benutzer und euren Server eintragen!
So. Das kommt dann zum Beispiel in die Datei vnctunnel.service.
sudo nano /etc/systemd/system/vnctunnel.serviceAb jetzt kann man wunderschön damit arbeiten!
sudo systemctl start vnctunnelDamit startet man seinen Tunnel.
Perfekt! Mit:
sudo systemctl stop vnctunnelbeendet man ihn wieder, wär hätte das für möglich gehalten!
Mit:
sudo systemctl status vnctunnelkann man dann auch noch den Status abfragen.
Wunderschön, oder?
Zum guten Schluss dann noch:
sudo systemctl enable vnctunnelund das Ding startet in Zukunft bei jedem Neustart automatisch mit. So soll es sein!
Das ist ganz einfach. Hat jemand meinen Artikel “Qemu mit VNC” gelesen? Nein, dann solltet ihr das jetzt nachholen, denn darum geht es jetzt.
So. Es ist also möglich, qemu so zu starten, dass hinten ein VNC dabei herausfällt. Na? Hat schon jemand eine Vermutung?
Korrekt. Mit einem solchen Tunnel ist es also auch möglich, von aussen auf eine virtuelle Maschine zuzugreifen! Da sage ich nur, entdecke die Möglichkeiten!
Es gibt da sogar ein Szenario, was ich wohl in naher Zukunft mal ausprobieren werde.
Kennt jemand das Spiel “Birth of the Federation“? Das ist ein Runden basiertes Strategiespiel zum Thema Star Trek aus dem Jahr 1999. Seit 2003, oder 2004 spiele ich es immer wieder mit einem sehr guten Freund von mir. Der Haken an der Sache ist jedoch, er hat einen Mac, oder spielt unter Windows, ich unter Linux. Nächster Haken, dieses Spiel will nicht mal eben über das Internet laufen. Es hat zwar eine Multiplayer-Schnittstelle, aber die funktioniert eigentlich nur im lokalen Netzwerk.
Gut. Nun könnte man einen VPN benutzen. Machen wir auch in der Regel. Bislang lief das unter Hamatchi. Warum? Weil wir es bislang nicht gebacken bekommen haben, ihn in mein VPN einzubinden. Warum? Weil ich so gar keine Ahnung habe, wie man das auf Windows macht. Gut, dass könnte ich mir noch aneignen, da auf meinem Laptop ja auch Windows10 läuft, aber Mac? Davon hab ich ja so gar keine Ahnung. Ich habe auch keinen Zugriff auf seinen Computer und schliesslich, wir wollen spielen und nicht immer nur an irgendetwas herumbasteln.
So. Das Spiel hat jetzt auch Berge von Mods. Zudem kann ich es unter Wine dazu zwingen, in einem Fenster zu laufen. Gut. Bei mir läuft dann also alles, aber wie ist es bei ihm? Dann geht hier was nicht, dann klappt da was nicht und ich hab so gar keine Ahnung, warum das so ist!
Jetzt festhalten! Ich mache das jetzt viel einfacher! VNC gibt es sowohl für Windows, wie auch für Mac. Es zu installieren ist ja auch kein Hexenwerk. Was liegt da also näher, als wenn ich mir einfach eine kleine VM zusammenbastele, dort alles fertig zum laufen bringe und dann starte? Er logt sich über VNC dann in die virtuelle Maschine ein, startet das Spiel mit den Mods, wir gehen über meinen VPN und alle sind glücklich?
Wahrscheinlich wird sich jetzt der Eine oder Andere denken, so könnte man doch auch gemütlich einen Webserver vom heimischen Rechner aus ins Netz tunneln. Ja, geht! Aber!
Alles unter Port 1024 erfordert auf dem Server Root-Rechte! Das heisst, ihr müsst euren Tunnel als Root aufbauen. Ich muss hoffentlich niemandem erzählen, dass ihr damit unter Umständen einem Angreifer Tür und Tor öffnet! Von daher bin ich da jetzt auch nicht drauf eingegangen. Wer es ausprobieren will, kann dies auf eigene Gefahr gerne tum. Ich übernehme keine Haftung!