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.

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.

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

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

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 ../

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.

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)

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.

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 commitauf. 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.

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
#

[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 Nausch 
Date:   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 Nausch 
Date:   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

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!

...

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.

 $ 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 Nausch 
Date:   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 Nausch 
Date:   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 Nausch 
Date:   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


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
@@ -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

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.

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'.