Verteilte Versionsverwaltung für Programmcode und Dokumente mit Hilfe von Git
Git ist ein freies und quelloffenes, verteiltes Versionskontrollsystem, welches Anfang 2005 von Linus Torvalds, dem Initiator und heutigen Maintainer des Linux-Kernels, entwickelt wurde. Mit Hilfe der verteilten Versionsverwaltung von lassen sich die Dateien eines Projektes einfach organisieren und an beliebiger Stelle erweitern, optimieren und deployen und so kann fast alles von kleinen bis zu sehr grossen Projekten schnell und effizient bearbeitet werden.
In einem verteilten System wie Git gibt es viele gleichwertige Instanzen des Repositorys, so dass jeder Entwickler über sein eigenes Repository verfügt. Der Austausch von Veränderungen ist flexibler und erfolgt nicht zwingend über einen zentralen Server. Bei einem zentralen System, wie z.B. Subversion, muss es einen zentralen Server geben, auf dem die Geschichte des Projekts gespeichert wird. Alle Entwickler müssen sich mit diesem Server verbinden, um die Versionsgeschichte einzusehen oder Änderungen vorzunehmen.
Grundlagen
Literatur
Zum Einlesen was Git insbesondere leisten kann, welche Einsatzgebiete es gibt, welche Unterschiede es zu zu anderen Versionsverwaltungstools wie z.B. Subversion oder CVS bietet, eigenen sich unter anderem folgende hervorragende Bücher, die auch online zur Verfügung stehen.
Pro Git von Apress
Das Git-Buch
Git und seine Befehlsoptionen
Einen schnellen Überblick über Git und seine Kommandos kann man mit Hilfe der Option --help
zur Ansicht bringen.
$ git --help
usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
These are common Git commands used in various situations:
start a working area (see also: git help tutorial)
clone Clone a repository into a new directory
init Create an empty Git repository or reinitialize an existing one
work on the current change (see also: git help everyday)
add Add file contents to the index
mv Move or rename a file, a directory, or a symlink
restore Restore working tree files
rm Remove files from the working tree and from the index
sparse-checkout Initialize and modify the sparse-checkout
examine the history and state (see also: git help revisions)
bisect Use binary search to find the commit that introduced a bug
diff Show changes between commits, commit and working tree, etc
grep Print lines matching a pattern
log Show commit logs
show Show various types of objects
status Show the working tree status
grow, mark and tweak your common history
branch List, create, or delete branches
commit Record changes to the repository
merge Join two or more development histories together
rebase Reapply commits on top of another base tip
reset Reset current HEAD to the specified state
switch Switch branches
tag Create, list, delete or verify a tag object signed with GPG
collaborate (see also: git help workflows)
fetch Download objects and refs from another repository
pull Fetch from and integrate with another repository or a local branch
push Update remote refs along with associated objects
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
See 'git help git' for an overview of the system.
Eine umfangreiche Dokumentation von Git liegt in Form vorinstallierter Manual-Pages vor, bei dem fast jedes Subkommando über eine eigene manpage verfügt. Die entsprechende Hilfeseiten erreicht man z.B. am Beispiel des Befehls git init
über folgende Varianten:
$ man git-init
$ git init --help
bzw.
$ git help status
Vorbereitende Konfiguration
Damit Git bei einem commit
die Änderungen einem Urheber zuordnen kann, werden wir zunächst ein paar grundlegende Einstellungen vornehmen.
$ git config --global user.name "Michael Nausch" $ git config --global user.email "django@nausch.org"
Optional können wir, sofern ausser uns kein anderer Nutzer, Zugriff auf den Rechner hat, auch ein Passwort für spätere git push
hinterlegen
$ git config --global user.password "0l1v3r157einec001350ck3!"
Da wir auf unserer Linux-Admin Workstation unseren gewohnten Editor vim
verwenden wollen, definieren wir diesen für git.
$ git config --global core.editor "vim"
$ git config –global color.ui auto
$ git config --list --show-origin
file:/home/django/.gitconfig user.name=Michael Nausch file:/home/django/.gitconfig user.email=django@nausch.org file:/home/django/.gitconfig user.password=0l1v3r157einec001350ck3! file:/home/django/.gitconfig core.editor=vim
$ ls -alF ~/.gitconfig
-rw-rw-r-- 1 django django 139 Apr 6 17:24 /home/django/.gitconfig
$ cat ~/.gitconfig
[user] name = Michael Nausch email = django@nausch.org password = 0l1v3r157einec001350ck3! [core] editor = vim
Git Beispielsprojekt - initiale Aufgaben
Arbeitsverzeichnis / Entwicklungsumgebung anlegen
Zunächst legen wir uns im Arbeitsverzeichnis Freifunk
im Home-Verzeichnis unseres Users ein Verzeichnis für unser Projekt (Repository) an.
$ mkdir -p $HOME/Freifunk/ffmuc-offloader_rpb4
Dieses Verzeichnis ist aktuell noch leer und ohne jedwede Inhalte.
$ ls -alF ~/Freifunk/ffmuc-offloader_rpb4
total 8 drwxrwxr-x 2 django django 4096 Apr 6 17:15 ./ drwxrwxr-x 4 django django 4096 Apr 6 17:15 ../
Erste Schritte mit Git
Nun können wir unser Repository git
bekannt machen und initialisieren.
$ git init ~/Freifunk/ffmuc-offloader_rpb4
Initialized empty Git repository in /home/django/Freifunk/ffmuc-offloader_rpb4/.git/
Im entsprechenden Verzeichnis finden wir nun das Verzeichnis .git
ls -alF ~/Freifunk/ffmuc-offloader_rpb4
total 12 drwxrwxr-x 3 django django 4096 Apr 6 17:33 ./ drwxrwxr-x 4 django django 4096 Apr 6 17:15 ../ drwxrwxr-x 7 django django 4096 Apr 6 17:33 .git/
$ tree /home/django/Freifunk/ffmuc-offloader_rpb4/.git/
/home/django/Freifunk/ffmuc-offloader_rpb4/.git/ ├── branches ├── config ├── description ├── HEAD ├── hooks │ ├── applypatch-msg.sample │ ├── commit-msg.sample │ ├── fsmonitor-watchman.sample │ ├── post-update.sample │ ├── pre-applypatch.sample │ ├── pre-commit.sample │ ├── pre-merge-commit.sample │ ├── prepare-commit-msg.sample │ ├── pre-push.sample │ ├── pre-rebase.sample │ ├── pre-receive.sample │ └── update.sample ├── info │ └── exclude ├── objects │ ├── info │ └── pack └── refs ├── heads └── tags 9 directories, 16 files
In diesem Verzeichnis verwaltet git intern unser Repository. Wir brauchen diesem in aller Regel keine besondere Beachtung schenken und vertrauen und verlassen uns da voll darauf, dass git hier alles nötige verwalten wird.
Nun können wir mit der Option status
den aktuellen Status unseres Verzeichnisses ansehen. Dazu wechseln wir zunächst in das zuvor angelegte Arbeitsverzeichnis.
$ cd ~/Freifunk/ffmuc-offloader_rpb4/
Anschliessend fragen wir den Status ab.
$ git status
On branch master No commits yet nothing to commit (create/copy files and use "git add" to track)
Was genau teilt uns nun git hier mit? Nun zum einen weist ins git zum einen darauf hin, dass wir vor unserem ersten commit stehen No commits yet
und zum anderen dass aktuell noch keinerlei Inhalte existieren nothing to commit
, die git aktuell in einen commit einfliessen lassen könnte.
Git ist aber so nett und gibt uns auch gleich einen Hinweis, was wir als nächsten tun sollten um diesen Makel zu beheben:
(create/copy files and use „git add“ to track)
Wir sollen also Dateien erstellen oder kopieren und mit Hilfe des Befehls git add
dann diesem Repo bzw. Git bekannt zu geben.
Ansible: Directory Layout anlegen
Da wir uns bei unserem Repository-Beispiel an den Ansible's Best Practices orientieren wollen, werden wir zunächst das Ansible Directory Layout anlegen.
Dieses Verzeichnis-Layout werden wir nun einfach und schnell auf den Weg bringen. Hierzu verwenden wir die nachfolgend gezeigten zwei Befehle bzw. genauer gesagt die beiden Befehlsketten:
$ mkdir -p ~/Freifunk/ffmuc-offloader_rpb4/inventories/{production,staging}/{group_vars,host_vars} \ ~/Freifunk/ffmuc-offloader_rpb4/{library,module_utils,filter_plugins} \ ~/Freifunk/ffmuc-offloader_rpb4/roles/common/{tasks,handlers,templates,files,vars,defaults,meta,library,module_utils,lookup_plugin}
$ touch ~/Freifunk/ffmuc-offloader_rpb4/inventories/{production,staging}/hosts.yml \ ~/Freifunk/ffmuc-offloader_rpb4/site.yml \ ~/Freifunk/ffmuc-offloader_rpb4/roles/common/{tasks,handlers,templates,files,vars,defaults,meta}/main.yml
Somit haben wir nun in unserem Repository Verzeichnis die gewünschte Struktur, das Ansible Directory Layout:
$ tree ~/Freifunk/ffmuc-offloader_rpb4
/home/django/Freifunk/ffmuc-offloader_rpb4 ├── filter_plugins ├── inventories │ ├── production │ │ ├── group_vars │ │ ├── hosts.yml │ │ └── host_vars │ └── staging │ ├── group_vars │ ├── hosts.yml │ └── host_vars ├── library ├── module_utils ├── roles │ └── common │ ├── defaults │ │ └── main.yml │ ├── files │ │ └── main.yml │ ├── handlers │ │ └── main.yml │ ├── library │ ├── lookup_plugin │ ├── meta │ │ └── main.yml │ ├── module_utils │ ├── tasks │ │ └── main.yml │ ├── templates │ │ └── main.yml │ └── vars │ └── main.yml └── site.yml 22 directories, 10 files
Rufen wir nun erneut den git status
informiert uns nunmehr Git wie folgt:
$ git status
On branch master No commits yet Untracked files: (use "git add..." to include in what will be committed) inventories/ roles/ site.yml nothing added to commit but untracked files present (use "git add" to track)
Hmmm eigentlich komisch, da wir doch auch z.B. ein Verzeichnis haben wie dies hier: ~/Freifunk/ffmuc-offloader_rpb4/filter_plugins
. Warum nur unterschlägt uns Git nun dieses Verzeichnis. Die Lösung finden wir in dem Hinweis Untracked files
. Git erfasst erst einmal „nur Inhalte, genauer gesagt Dateien. Leere Verzeichnisse werden erst einmal ignoriert!
Wir werden also, dem Vorschlag von Git die drei rot markierten Zeilen mit einm git add
Git bekannt geben.
$ git add inventories/ $ git add roles/ $ git add site.yml
Nun rufen wir erneut git status
auf.
On branch master No commits yet Changes to be committed: (use "git rm --cached..." to unstage) new file: inventories/production/hosts.yml new file: inventories/staging/hosts.yml new file: roles/common/defaults/main.yml new file: roles/common/files/main.yml new file: roles/common/handlers/main.yml new file: roles/common/meta/main.yml new file: roles/common/tasks/main.yml new file: roles/common/templates/main.yml new file: roles/common/vars/main.yml new file: site.yml
Nun ist es an der Zeit unseren ersten Commit um damit unsere Dateien Git zur Verwaltung anzuvertrauen; Git markiert die neu gefundenen Datei grün und markiert diese als new file:
. Dieser Commit wurde aber noch nicht vollzogen, sondern erst nur vorbereitet! Git sammelt die so markierten Dateien im sog. Index und merkt sich intern so die Inhalte vor, die beim nächsten Commit mit einfliessen sollen.
Unser erster Commit
Nun ist es an der Zeit für unseren ersten initialen commit
. Ein Commit manifestiert den Stand aller Dateien unseres Projekts fest definiertem Zeitpunkt und beinhalten u.a. folgende Metadaten:
- Name des Authors inkl. seiner eMail-Adresse,
- Name des Committers ebenfalls mit seiner eMail-Adresse,
- Erstellungsdatum, sowie das
- Datum des Commits.
Wir rufen den Befehl git
mit der Option commit
auf. Wir können Optional mit dem Parameter -m
die sog. Commit Message mitgeben. Wir werden aber bereits bei unserem ersten Commit nicht diese Option nutzen sondern den Commit nur mit git commit
anstossen.
Warum machen wir das? Nun, wir gewöhnen uns am besten von vorne herein eine saubere strukturierte Arbeitsweise an. Dies hilft uns und anderen später wesentlich bei der Nachvollziehbarkeit der einzelnen Commits und deren Dokumentation!
Am besten überlegen wir uns auch vorab, in welcher Sprache unsere Commit-Nachrichten verfasst werden sollen. Wer ist unser Publikum unser Kunde? Für private Projekte oder Projekten lokal agierender Gruppierungen bietet sind vermutlich Deutsch als grösster gemeinsamer Nenner an. Will man sein Projekt einem internationalen Publikum angedeihen lassen, wird vermutlich eher Englisch die gewählte Sprache sein. Ein Mischmasch ist sicherlich etwas was keinem so recht weiter helfen wird.
Um Commit Nachrichten besser lesbar zu halten, haben sich folgende Rahmenbedingungen als praktikabel erwiesen:
- Sprache gemäss dem Zielpublikum/Einsatz wählen, entweder Deutsch oder Englisch aber kein Mischmasch
- Erste Zeile beinhalten eine Zusammenfassung (max. 50 Zeichen)
- zweite Zeile leer lassen
- Ab Zeile drei Beschreibung des Commits mit einer max. Zeilenlänge von 76 Zeichen
Beim Verfassen der Commit-Beschreibung achten wir daher auf folgende Dinge:
- Wir erzwingen niemals leere Commit-Beschreibungen, ebenso wenig wie Kurzbeschreibungen Bugfix, Fix, Update, Verbesserung etc.pp.!
- Wir dokumentieren warum wir etwas ergänzt, gelöscht oder verändert haben und weisen auch darauf hin, welche Folgen diese Änderungen ggf. nach sich ziehen könnten/werden. Was genau verändert wurde brauchen wir nicht extra zu beschreiben, da dies aus dem Diff angezeigt werden kann!
- Wir sind selbstkritisch und ehrlich und weisen ggf. darauf hin, wenn wir der Meinung sind, dass ggf. noch weiterer Verbesserungs-/Optimierungs-/Korrekturbedarf besteht!
Wir führen also nun unseren ersten commit durch und rufen den Git-Befehl commit
auf.
$ git commit
Da wir als Editor unseren Standard-Editor vim
gewählt hatten, befinden wir uns nun im Vim-Editor uns sehen folgende Seite:
# Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch master # # Initial commit # # Changes to be committed: # new file: inventories/production/hosts.yml # new file: inventories/staging/hosts.yml # new file: roles/common/defaults/main.yml # new file: roles/common/files/main.yml # new file: roles/common/handlers/main.yml # new file: roles/common/meta/main.yml # new file: roles/common/tasks/main.yml # new file: roles/common/templates/main.yml # new file: roles/common/vars/main.yml # new file: site.yml #
Neben Hinweisen zur Vorlage sehen wir auch noch welche Änderungen commited werden sollen. Gemäss, unserer Vorüberlegungen zu den Commit-Nachrichten tragen wir nun in die erste Zeile eine kurze Zusammenfassung (Überschrift ein, die von einer Leerzeile gefolgt wird. Ab Zeile drei beschreiben wir dann, was genau wir geändert haben.
Initialer Commit. Ansible Directory Layout angelegt. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch master # # Initial commit # # Changes to be committed: # new file: inventories/production/hosts.yml # new file: inventories/staging/hosts.yml # new file: roles/common/defaults/main.yml # new file: roles/common/files/main.yml # new file: roles/common/handlers/main.yml # new file: roles/common/meta/main.yml # new file: roles/common/tasks/main.yml # new file: roles/common/templates/main.yml # new file: roles/common/vars/main.yml # new file: site.yml #Wir Verlassen nun unseren Editor VIM und
git
gibt noch eine Zusammenfassung des commits aus.
[master (root-commit) f5cd46e] Initialer Commit. 10 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 inventories/production/hosts.yml create mode 100644 inventories/staging/hosts.yml create mode 100644 roles/common/defaults/main.yml create mode 100644 roles/common/files/main.yml create mode 100644 roles/common/handlers/main.yml create mode 100644 roles/common/meta/main.yml create mode 100644 roles/common/tasks/main.yml create mode 100644 roles/common/templates/main.yml create mode 100644 roles/common/vars/main.yml create mode 100644 site.yml
Rufen wir nun den Status von Git erneut ab sehen wir, dass keine weiteren Dateien mehr anstehen, die eines commits bedürften.
$ git status
On branch master nothing to commit, working tree clean
Eine Zusammenfassung unseres gerade ausgeführten Commits können wir mit dem Befehl git show --shortstat
abrufen.
commit f5cd46ef0bbd7816edddefde79b2179de995e865 (HEAD -> master) Author: Michael NauschDate: Wed Apr 6 19:53:37 2022 +0200 Initialer Commit. Ansible Directory Layout angelegt. 10 files changed, 0 insertions(+), 0 deletions(-)
Eine ausführlichere und detaillierte Aufstellung erhalten wir, wenn wir bei obigen Aufruf dir Option --shortstat
weglassen.
$ git show
commit f5cd46ef0bbd7816edddefde79b2179de995e865 (HEAD -> master) Author: Michael NauschDate: Wed Apr 6 19:53:37 2022 +0200 Initialer Commit. Ansible Directory Layout angelegt. diff --git a/inventories/production/hosts.yml b/inventories/production/hosts.yml new file mode 100644 index 0000000..e69de29 diff --git a/inventories/staging/hosts.yml b/inventories/staging/hosts.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/defaults/main.yml b/roles/common/defaults/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/files/main.yml b/roles/common/files/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/handlers/main.yml b/roles/common/handlers/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/meta/main.yml b/roles/common/meta/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/tasks/main.yml b/roles/common/tasks/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/templates/main.yml b/roles/common/templates/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/roles/common/vars/main.yml b/roles/common/vars/main.yml new file mode 100644 index 0000000..e69de29 diff --git a/site.yml b/site.yml new file mode 100644 index 0000000..e69de29
Alternativ können wir uns beim Befehl show
auch den HEAD, master, die commit-ID odcer Teile der commit-ID auswählen. Folgende Beispiele wären also gleichwertig.
$ git show HEAD $ git show master $ git show f5cd46ef0bbd7816edddefde79b2179de995e865 $ git show f5cd46
Unser zweiter Commit
Bei unserem Beispielprojekt haben wir für unser Ansible-Projekt ein Inventory definiert und angelegt.
$ tree inventories/production/
inventories/production/ ├── group_vars │ ├── gateway_keys │ ├── gateway_link_adresses │ ├── gateway_mesh_vpn_vxlan_ids │ ├── global_vars │ ├── vxlan_ids │ └── wireguard_ports ├── hosts └── host_vars └── rpb4-ol-a
$ git tag -a v7.0
v7.0 - Redisign und aktualisiertes Git-Repository # # Write a message for tag: # v7.0 # Lines starting with '#' will be ignored.
$ git log
commit 2be6d73d053d103e850af8e6507f8da8b7333bd7 (HEAD -> master, tag: v7.0) Author: Michael Nausch <django@nausch.org> Date: Fri Apr 8 20:27:02 2022 +0200 Vorerst V7.0 fertig gestellt. Erweiterung des playbocks um die angelegte role final. Hierfür die role final angefügt, bei der letztendlich nur folgende Aufgabe erledigt wird: - Reboot nach Abschluss des Baus unseres Offloaders. Zu ignorierende Dateien in der Konfigurationsdatei .gitignore definiert, sowie Lizenz und README-Datei für den Upload bei GitHub angefügt. Da es aktuell Probleme mit der Installation und Konfiguration eines OLE-Display von AZDelivery gibt, wurde die zugehörige Rolle aus früheren Versionen erst einmal exkludiert. Diese Funktion wir in einem künftigen neune Branch bzw. Version dann hoffentlich wieder nachgereicht - bitte also noch um etwas Gelduld hierzu! ...
Kürzere Commit-Hashes
Bei einigen Git Befehlen ist die Angabe des Commit-Hashes wie z.B. 2be6d73d053d103e850af8e6507f8da8b7333bd7
notwendig. Die Verwendung des vollständigen SHA1 Hash-Wertes kann mit unter als sehr umständlich betrachtet werden. Git benötigt nicht unbedingt den vollständigen Hash-wert, sondern kann auch nur mit den ersten Stellen des Hashes, sofern dieser eindeutig ist, arbeiten. Neben der individuellen manuellen Verkürzung des Hashes bietet Git auch die Möglichkeit einer Vereinfachung beim Arbeiten. Als Unterstützung bei der Handhabung für solche eindeutigen, kann git log
auch wie folgt verwendet werden.
$ git log --abbrev-commit
Git zeigt somit automatisch eine verkürzte siebenstellige eindeutige Länge an, die wir bei der Angabe der betreffenden Git Kommandos dann statt des vollständigen SHA1 Hashwertes verwenden können.
kompremmierte verkürzte Git Logs
$ git log --oneline
2be6d73 (HEAD -> master, tag: v7.0) Vorerst V7.0 fertig gestellt. 2239227 Neue role client-mesh angefügt. daf72d5 Neue role hostapd angefügt. 55fd7e5 Neue role ext-respondd angefügt. 91fd641 Neue role vxlan angefügt. 0b490b9 Neue role wireguard angefügt. 1fff5ac Neue role batman angefügt f780de1 Roles bereinigt und basic role angelegt. aadeb57 Ansible-Inventory für den Offloader angelegt. f5cd46e Initialer Commit.
Dieses doch schon etwas umfangreicheren Änderungen haben wir nun wie gewohnt commited. Um herauszufinden was genau nun verändert und hinzugefügt wurde sehen wir uns nun im Detail in unserem Projekt-Repository mit Hilfe von Git an.
Zunächst einmal checken wir, wieviel Commits es bis jetzt gab. Dazu benutzen wir die Option --oneline
beim Git-Befehl log
$ git log --oneline
316adae (HEAD -> master)Ansible-Inventory für den Offloader angelegt f5cd46e Initialer Commit.
Es ist also „nur“ ein neuer Commit mit dedr ID 316adae
welche der Author mit der Überschrift Ansible-Inventory für den Offloader angelegt
versehen hat.
Die genaue Beschreibung der einzelnen Commits lassen wir uns wie gewohnt mit git log
anzeigen.
commit 316adae816a876e3858ec9bc30c7eee4f6a207a9 (HEAD -> master) Author: Michael NauschDate: Wed Apr 6 21:16:22 2022 +0200 Ansible-Inventory für den Offloader angelegt Zur Erstellung eines Offloaders im Freifunk München Netz benötigen wir ein Inventory. Dieses Inventory (ini-Style) beinhaltet neben Gruppen- und Host-Definitionen allgemeine Parameter (Gruppen-Variablen) aus dem Freifunk-München Netz, wie auch Nodespezifische Parameter, (Host- Variablen) die den Offloader selbst beschreiben. Der Nodebetreiber muss die Nodespezifischen Definitionen vor dem Starten des Ansible Playbooks dann noch seinen Gegebenheiten vor Ort anpassen. Nähere Informationen hierzu findet man in der zum Projekt passenden Seite in Djangos WIKI: https://dokuwiki.nausch.org/doku.php/centos:ansible:ffmuc-rpb4-ol commit f5cd46ef0bbd7816edddefde79b2179de995e865 Author: Michael NauschDate: Wed Apr 6 19:53:37 2022 +0200 Initialer Commit. Ansible Directory Layout angelegt.
Nun wollen wir aber doch mal ganz genau wissen, was der Author des Projekts denn wirklich alles abgeändert hat. Dazu benutzen wir wieder den Git-Befehl show
.
$ git show
Wir befinden uns nun in einer Art „vim -R“ Ansicht, in der wir wie gewohnt mit den Pfeil- und Bild-Tasten, oder z.B. mit G
zum Ende der Seite und mit g#
zum Anfang der Seite springen können. Mit der Taste q
verlassen wir dann die Ansicht wieder zum Schluss.g
commit 316adae816a876e3858ec9bc30c7eee4f6a207a9 (HEAD -> master) Author: Michael NauschDate: Wed Apr 6 21:16:22 2022 +0200 Ansible-Inventory für den Offloader angelegt Zur Erstellung eines Offloaders im Freifunk München Netz benötigen wir ein Inventory. Dieses Inventory (ini-Style) beinhaltet neben Gruppen- und Host-Definitionen allgemeine Parameter (Gruppen-Variablen) aus dem Freifunk-München Netz, wie auch Nodespezifische Parameter, (Host- Variablen) die den Offloader selbst beschreiben. Der Nodebetreiber muss die Nodespezifischen Definitionen vor dem Starten des Ansible Playbooks dann noch seinen Gegebenheiten vor Ort anpassen. Nähere Informationen hierzu findet man in der zum Projekt passenden Seite in Djangos WIKI: https://dokuwiki.nausch.org/doku.php/centos:ansible:ffmuc-rpb4-ol @@ -0,0 +1,6 @@ +# aus https://github.com/freifunkMUC/site-ffm/blob/stable/domains/ "publickey" +gw_publickey: + gw04: "TszFS3oFRdhsJP3K0VOlklGMGYZy+oFCtlaghXJqW2g=" + gw05: "igyqOmWiz4EZxPG8ZzU537MnHhaqlwfa7HarB3KmnEg=" + gw06: "pkRaUOoLuuHnUt9BEGeKrhF3OMYBPecc0iYkika6uhE=" + gw07: "PcKkakZcTEx3LKh+G06Opb8/esg08aWK33A5/Ff1YXE=" diff --git a/inventories/production/group_vars/gateway_link_adresses b/inventories/production/group_vars/gateway_link_adresses new file mode 100644 index 0000000..b57913e --- /dev/null +++ b/inventories/production/group_vars/gateway_link_adresses @@ -0,0 +1,6 @@ +# aus https://github.com/freifunkMUC/site-ffm/blob/stable/domains/ "link_address" +gw_linklocal: + gw04: "fe80::27c:16ff:fec0:6c74" + gw05: "fe80::281:8eff:fef0:73aa" + gw06: "fe80::2a2:e4ff:fef9:2269" + gw07: "fe80::23b:d2ff:fe95:967f" diff --git a/inventories/production/group_vars/gateway_mesh_vpn_vxlan_ids b/inventories/production/group_vars/gateway_mesh_vpn_vxlan_ids new file mode 100644 index 0000000..57b843f --- /dev/null +++ b/inventories/production/group_vars/gateway_mesh_vpn_vxlan_ids @@ -0,0 +1,15 @@ +# https://ffmuc.net/wiki/doku.php?id=knb:rpb4_wg#berechnung_der_mesh_vpn_vxlan_id +gw_vxlan_ids: + muc_cty: 3836090 + muc_nord: 1920014 + muc_ost: 12097488 + muc_sued: 12815947 + muc_west: 29149 + uml_nord: 403289 + uml_ost: 12645856 + uml_sued: 12090508 + uml_west: 935867 + gauting: 4681119 + freising: 4669918 + welt: 4831583 + augsburg: 2962115 diff --git a/inventories/production/group_vars/global_vars b/inventories/production/group_vars/global_vars new file mode 100644 index 0000000..5175e72 --- /dev/null +++ b/inventories/production/group_vars/global_vars @@ -0,0 +1,2 @@ +ansible_ssh_user: pi +dtparam: "i2c_arm=on"/font> diff --git a/inventories/production/group_vars/vxlan_ids b/inventories/production/group_vars/vxlan_ids new file mode 100644 index 0000000..e1db8fd --- /dev/null +++ b/inventories/production/group_vars/vxlan_ids @@ -0,0 +1,15 @@ +# Die vxlan id berechnet sich aus dem domain_seed: https://ffmuc.net/wiki/doku.php?id=knb:rpb4_wg#mesh_per_vxlan1 +vxlan_ids: + muc_cty: 10758607 + muc_nord: 15521492 + muc_ost: 2948862 + muc_sued: 8599288 + muc_west: 7318933 + uml_nord: 5705961 + uml_ost: 4892713 + uml_sued: 16544703 + uml_west: 16677749 + gauting: 16175732 + freising: 12937858 + welt: 16306234 + augsburg: 10700201 diff --git a/inventories/production/group_vars/wireguard_ports b/inventories/production/group_vars/wireguard_ports new file mode 100644 index 0000000..874d184 --- /dev/null +++ b/inventories/production/group_vars/wireguard_ports @@ -0,0 +1,14 @@ +wireguard_ports: + muc_cty: 40002 + muc_nord: 40003 + muc_ost: 40004 + muc_sued: 40005 + muc_west: 40006 + uml_nord: 40007 + uml_ost: 40008 + uml_sued: 40009 + uml_west: 40010 + gauting: 40012 + freising: 40013 + welt: 40011 + augsburg: 40014 diff --git a/inventories/production/host_vars/rpb4-ol-a b/inventories/production/host_vars/rpb4-ol-a new file mode 100644 index 0000000..9f09905 --- /dev/null +++ b/inventories/production/host_vars/rpb4-ol-a @@ -0,0 +1,19 @@ +# IP-Adresse unseres Raspberry in unserem eigenen lokalen Netzwerk +# Alugehäuse ohne Lüfter und ohne Display +# MAC: dc:a6:32:5c:46:07 +ansible_ssh_host: 192.168.0.23 +ansible_port: 22 +ansible_user: pi +ansible_ssh_private_key_file: ~/.ssh/id_ed25519_freifunk +# +batman_adv_version: "2020.4" +ffmuc_segment: "muc_ost" +ffmuc_gateway: "gw06" +raspberry_hostname: "ff_pliening_rpb4_ol_v6a" +node_contact_address: "hier entlang => https://bit.ly/2VxGoXp" +raspberry_latitude: "48.198790640" +raspberry_longitude: "11.798020899" +raspberry_wifi: "nein" +raspberry_clientvlan: "7" +raspberry_meshvlan: "8" +raspberry_oled: "nein" diff --git a/inventories/production/hosts b/inventories/production/hosts new file mode 100644 index 0000000..637a3af --- /dev/null +++ b/inventories/production/hosts @@ -0,0 +1,7 @@ +# Django : 2022-04-06 + +# Definition einer Hostgruppe "ffmuc" +[ffmuc] + +# Auflistung aller Hosts, die der vorgenannten Hostgruppe angehören. +rpb4-ol-a diff --git a/inventories/production/hosts.yml b/inventories/production/hosts.yml deleted file mode 100644 index e69de29..00000
diff --git a/inventories/production/group_vars/gateway_keys b/inventories/production/group_vars/gateway_keys new file mode 100644 index 0000000..8009916 --- /dev/null +++ b/inventories/production/group_vars/gateway_keys
Git Index
Solange wir nicht mit einem commit
die Daten aus Index nicht in unser Repository übertragen, werden alle Änderungen die wir mit einem git add
dem Index hinzufügen und mit reset
wieder entziehen, lediglich im Index zwischengespeichert.
Fragen wir nun den Status unser Umgebung ab.
$ git status
On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean
Die Ausgabe working tree clean bedeutet hier nicht, dass der Index „leer“ wäre, sondern dass der Working Tree
und der Index
synchron sind, also dass der Index
im gleichen Zustand wie der Working Tree
ist!
Was passiert nun beim Aufruf von git diff
wenn Working Tree
und Index
synchron sind?
$ git diff
Ist die Ausgabe „leer“ bedeutet dies, dass diese gleich sind, ein Versuch mit einem git commit
fehlschlagen wird, da ja nichts im Zwischenspeicher/Index vorgemerkt siot, was in das Repository
überführt werden könnte.
$ git commit
On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean
Mit der Option –staged
können wir und beim Befehl git diff
den Unterschied zwischen unserem Index (Staging Area) und unserem Repository
ausgeben lassen. Haben wir Änderungen im Index vorgemerkt würde dies den Unterschied zum aktuellen HEAD
sehen.
Im Ausgangszustand, also wenn wir unsere Umgebung mit einem git init
inital angelegt haben, oder nach einem durchgeführten git commit
erzeugt t weder ein git diff
noch ein git diff –staged
eine Ausgabe.
GitHub
Quick setup — if you’ve done this kind of thing before or Get started by creating a new file or uploading an existing file. We recommend every repository include a README, LICENSE, and .gitignore. …or create a new repository on the command line echo "# ffmuc-offloader_rpb4" >> README.md git init git add README.md git commit -m "first commit" git branch -M main git remote add origin https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git git push -u origin main …or push an existing repository from the command line git remote add origin https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git git branch -M main git push -u origin main …or import code from another repository You can initialize this repository with code from a Subversion, Mercurial, or TFS project.
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
$ git remote add origin https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git $ git branch -M main $ git push -u origin main
Enumerating objects: 169, done. Counting objects: 100% (169/169), done. Delta compression using up to 8 threads Compressing objects: 100% (155/155), done. Writing objects: 100% (169/169), 41.24 KiB | 1.59 MiB/s, done. Total 169 (delta 25), reused 0 (delta 0) remote: Resolving deltas: 100% (25/25), done. To https://github.com/Django-BOfH/ffmuc-offloader_rpb4.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.