Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- linux:ansible:playbook_example_09 [23.09.2022 10:12. ] – [Ansible-Konfigurationsdatei und Inventory-Definition] django
+++ linux:ansible:playbook_example_09 [19.11.2024 13:26. ] (aktuell) – [Ansible - Erweiterte Konfigurationsbeispiel: Inventory] django
@@ Zeile 4: / Zeile 4: @@
 Nachdem wir uns bereits eingehend mit den **[[basics#grundlagen|Grundlagen]]**, mit der **[[basics#installation|Installation von Ansible]]** und auch schon mit der Grundkonfiguration beschäftigt sowie erste Erfahrungen mit **[[playbooks|Playbooks]]** gesammelt haben, wollen wir uns nun mit der tiefer gehenden Konfiguration von Ansible beschäftigen. Ein wesentlicher Punkt, den wir bei unseren Überlegungen im Kapitel **[[detail|Ansible - Erweiterte Konfigurationsbeispiele]]** angestellt hatten, war unter anderem **//Woher beziehen wir die Hostdefinitionen und deren Eigenschaften?//**.
-Klar ist natürlich dass sich da eine Hobby-mässige Installation mit einer Hand voll Geräten sich wohl erheblich von einer professionellen Umgebung mit hunderten oder gar mehr Hosts unterscheiden wird. Bei ersteren wird man vermutlich alle Information bestmöglich versuchen z.B. in einer Datei oder in einem Verzeichnis vor zuhalten. Bei grösseren Installationen wird man hingegen eine **CMDB**((**C**onfiguration **M**anagement **D**ata**B**ase)) zurück greifen und dort die Informationen pflegen, wie z.B.:
+Klar ist natürlich dass sich da eine Hobby-mässige Installation mit einer Hand voll Geräten sich wohl erheblich von einer professionellen Umgebung mit hunderten oder gar mehr Hosts unterscheiden wird. Bei ersteren wird man vermutlich alle Information bestmöglich versuchen z.B. in einer Datei oder in einem Verzeichnis vor zuhalten. Bei grösseren Installationen wird man hingegen eine **[[#cmdb-basierte_professionelle_umgebungen|CMDB]]**((**C**onfiguration **M**anagement **D**ata**B**ase)) zurück greifen und dort die Informationen pflegen, wie z.B.:
+  * **[[https://netboxlabs.com/docs/netbox/en/stable/|netbox]]**
   * **[[https://www.cmdbuild.org|CMDBuild -Platform for Asset Management]]**
   * **[[https://www.i-doit.org/|i-doit - Open Source CMDB & ITSM Tool ]]**
   * **[[https://www.combodo.com/itop-193|iTop - IT Service Management & CMDB iTop - IT Service Management & CMDB]]**
-Egal was wir als Bai verwenden, Ziel sollte immer sein aus den aktuell gepflegten Daten alle Informationen so für Ansible aufzubereiten, dass alle relevanten Daten, die zum Abarbeiten eines Playbooks benötigt werden, auch zur Verfügung stehen.
+Egal was wir als Basis verwenden, Ziel sollte immer sein aus den aktuell gepflegten Daten alle Informationen so für Ansible aufzubereiten, dass alle relevanten Daten, die zum Abarbeiten eines Playbooks benötigt werden, auch zur Verfügung stehen.
 ===== Inventory =====
@@ Zeile 145: / Zeile 146: @@
 Die YAML-Konfigurationsdatei enthält entsprechende Bemerkungen, die die einzelnen Blöcke und Funktionen ausreichend beschreiben. Wie können so individuelle und Anwendungsspezifische Lösungen abbilden.
-<WRAP center round info 100%>
+<WRAP center round info 80%>
-Natürlich gilt zu bedenken, dass das gezeigte Beispiel mit nur 8 Hosts und überschaubaren Variablen doch schon recht umfangreich geworden ist, wenn dies alles in eine Inventory-Datei gepackt wird. Bei Dutzenden oder Hunderten von Maschinen wird dies dann daraus schwer zu handeln - von verschachtelten Gruppen in Gruppen, oder Hosts die Mitglied in mehreren Gruppen sein sollen, sprechen wir dann besser gar nicht. Hier werden wir später auf eine **[[#inventarisierung_groesserer_umgebungen|andere/aufgeteilte Lösung]]** einschwenken müssen.
+Natürlich gilt zu bedenken, dass das gezeigte Beispiel mit nur 8 Hosts und überschaubaren Variablen doch schon recht umfangreich geworden ist, wenn dies alles in eine Inventory-Datei gepackt wird. Bei Dutzenden oder Hunderten von Maschinen wird dies dann daraus schwer zu handeln - von verschachtelten Gruppen in Gruppen, oder Hosts die Mitglied in mehreren Gruppen sein sollen, sprechen wir dann besser gar nicht.
+<WRAP center round alert 90%>
+Wollen wir später auch noch vertrauliche Informationen in einzelnen **''vault''**-Dateien vorhalten werden wir mit einer derartigen Inventarisierung Grenzen stossen!
+</WRAP>
+Hier werden wir später auf eine **[[#komplexere_und_groessere_umgebungen|andere/aufgeteilte Lösung]]** einschwenken müssen.
 </WRAP>
@@ Zeile 153: / Zeile 161: @@
 <html>
 <pre class="code">
-<font style="color: rgb(25, 100, 5)">localhost | SUCCESS => {
+<font style="color: rgb(25, 100, 5)">www7.dmz.nausch.org | SUCCESS => {
     "ansible_facts": {
         "discovered_interpreter_python": "/usr/bin/python2.7"
@@ Zeile 160: / Zeile 168: @@
     "ping": "pong"
 }</font>
+<font style="color: rgb(0, 0, 0)">
-<font style="color: rgb(0, 0, 0)...</font>
+...
+</font>
+<font style="color: rgb(239, 41, 41)">www8.dmz.nausch.org | UNREACHABLE! => {
+    "changed": false,
+    "msg": "Failed to connect to the host via ssh: ssh: connect to host 10.0.0.90 port 22: No route to host",
+    "unreachable": true
+}</font>
+<font style="color: rgb(0, 0, 0)">
+...</font>
 </pre>
 </html>
+==== Komplexere und grössere Umgebungen ====
+Wie schon im vorhergehenden Beispiel angemerkt, wird es bei einer grösseren Anzahl von Hostdefinitionen mit umfangreichen oder verschachtelten (Gruppe in Gruppe) Gruppenzugehörigkeiten mit verschiedensten zugeordneten Variablen sehr schnell "schmutzig". All das in einer ein zigsten Konfiguration abbilden zu wollen, wird man vermutlich in die Ecke "Hang zu masochistischen Tendenzen" oder Selbstgeisselung eines Admins einordnen - kurzum hier muss ein anderer Lösungsansatz her!
+In dem nachfolgenden Konfigurationsbeispiel sehen wir uns eine kleinere Installation an, die zwar nicht genau dem Kriterien **"gross"**, aber an Hand dieses Beispiels lässt sich das grundsätzliche Struktur und der Umgang mit verschachtelten Gruppen anschaulich erklären. Wir gehen bei diesem Beispiel von einer mittleren Freifunk-Installation mit folgenden unterschiedlichen Systemkomponenten und -eigenschaften aus.  aus:
+  * **Standard-Nodes**: Dies sind einfach ausgedrückt Standard-WLAN-Access-Points((**A**ccess **P**oint)), die für Endanwender einen Zugang zum Internet bereitstellen. In einfachen Installationen spannen diese einen Tunnel in Richtung des zentralen Gateways auf. Auf diesen Nodes läuft in aller Regel eine Firmware, die auf dem **[[https://github.com/freifunk-gluon/gluon|Gluon-Framework]]** sowie **[[https://openwrt.org/|OpenWrt]]** basiert.
+  * **Offloader**: Bei entsprechenden Verkehrsmengen (Traffic und Nutzer) nutzt man meist in kleinen vermaschten Netzen sog. Offloader, die leistungsfähigere Hardware verbaut haben um einen Tunnel zum zentralen Gateway der Freifunk Community aufzuspannen. Als Offloader kommen meist **x86-Hardware** in Form von **futro-thinclients**, virtualisierte Systeme **KVM** oder auch **Raspberry 4** Auf letzterem läuft als Betriebssystem ein spezielles Debian, auf den beiden anderen i.d.R. **Gluon**.
+In unserem Konfigurationsbeispiel haben wir folgende Komponenten und (Betriebs-)Systeme im Einsatz, woraus sich unterschiedliche Gruppenkonstellationen ergeben, die im Betrieb zum Tragen kommen bzw. verwendet werden.
+  - **Gruppe** aller WiFi-AccessPoints mit **Gluon** **''ffmuc''**:
+    * ff_pliening_gbw_cpod
+    * ff_pliening_gbw_dod
+    * ff_pliening_gbw_egod
+    * ff_pliening_gbw_ogod
+    * ff_pliening_gbw_ug
+    * ff_roding_as_nausch
+  - **Gruppe** aller Offloader **''olall''**:
+    * ff_pliening_gbw_client
+    * ff-django-raspi
+    * ff_pliening_gbw_futro_mesh
+    * ff_pliening_gbw_kvm_ol
+  - **Gruppe** **''gluonall''** aller Gluon-Systeme
+    * ff_pliening_gbw_cpod
+    * ff_pliening_gbw_dod
+    * ff_pliening_gbw_egod
+    * ff_pliening_gbw_ogod
+    * ff_pliening_gbw_ug
+    * ff_roding_as_nausch
+    * ff_pliening_gbw_futro_mesh
+    * ff_pliening_gbw_kvm_ol
+  - **Gruppe** **''olfutro''** der Offloader mit Futro-Hardware:
+    * ff_pliening_gbw_futro_mesh
+  - **Gruppe** **''ololkvm''** der KVM virtualisierten Offloader:
+    * ff_pliening_gbw_kvm_ol
+  - **Gruppe** **''olgluon''** aller Offloader mit **Gluon**
+    * ff_pliening_gbw_futro_mesh
+    * ff_pliening_gbw_kvm_ol
+  - **Gruppe** **''oldeb''** aller Offloader mit **Debian**
+    * ff_pliening_gbw_futro_mesh
+    * ff_pliening_gbw_kvm_ol
+  - **Gruppe** **''all''** aller Nodes:
+    * ff_pliening_gbw_cpod
+    * ff_pliening_gbw_dod
+    * ff_pliening_gbw_egod
+    * ff_pliening_gbw_ogod
+    * ff_pliening_gbw_ug
+    * ff_roding_as_nausch
+    * ff_pliening_gbw_client
+    * ff-django-raspi
+    * ff_pliening_gbw_futro_mesh
+    * ff_pliening_gbw_kvm_ol
+Nachfolgendes Schaubild visualisiert die einzelnen Gruppen und die entsprechenden Überlappungen.
+{{ :centos:ansible:inventory.png?direct&900 |Bild: Übersicht einer möglichen (Infra)Struktur}}
+=== inventory - Beispiel ===
+Die **Inventory**-Datei **''inventory.yml''** unseres Beispiels legen wir im Arbeitsverzeichnis unseres Ansible-Administrationshost ab.
+   $ vim ~/ansible/inventories/production/inventory.yml
+<file bash ~/ansible/inventories/production/inventory.yml>--- #Inventory - YAML syntax
+all:
+  children:
+    ffmuc:
+      hosts:
+        ff_pliening_gbw_cpod:
+        ff_pliening_gbw_dgod:
+        ff_pliening_gbw_egod:
+        ff_pliening_gbw_ogod:
+        ff_pliening_gbw_ug:
+        ff_roding_as_nausch:
+    oldeb:
+      hosts:
+        ff_pliening_gbw_client:
+        ff-django-raspi:
+    olfutro:
+      hosts:
+        ff_pliening_gbw_futro_mesh:
+    olkvm:
+      hosts:
+        ff_pliening_gbw_kvm_ol:
+    olgluon:
+      children:
+        olkvm:
+        olfutro:
+    olall:
+      children:
+        oldeb:
+        olgluon:
+    gluonall:
+      children:
+        ffmuc:
+        olgluon:
+    ffmucall:
+      children:
+        ffmuc:
+        olall:
+... #YAML end syntax
+</file>
+Die Datei ist relativ übersichtlich und doch recht einfach zu verstehen. Würden wir nun aber die Host- und Gruppenspezifischen Variablen mit in die Datei aufnehmen, wäre dies jedoch gänzlich anders. Dabei haben wir hier nur 10 Hosts und noch keine 100 oder noch mehr.
+Ansible bietet daher einen skalierbareren Ansatz, um den Überblick über Host- und Gruppenvariablen zu behalten. Man kann für jeden Host und jede Gruppe die Variablen in einer jeweils zugehörigen Datei auslagern. Ansible wir beim Aufruf und Abarbeiten eines Playbooks diese hostspezifischen Dateien im Verzeichnis **''host_vars''** und die gruppenspezifischen Variablen im Verzeichnis **''group_vars''**. Diese Verzeichnisse werden von Ansible entweder im dem Verzeichnis erwartet, in dem das aufgerufene Playbook gespeichert wurde oder alternativ dazu im Verzeichnis in dem das die **Inventory**-Datei gespeichert wurde.
+Diese beiden Verzeichnisse wurden bereits bei der initialen Konfiguration unserer Ansible-Umgebung mit Hilfe des Ansible-Playbooks **''[[playbook_example_08#aufgabenstellung_2_-_erweiterte_grund-_basis-installation_fuer_ansible-vault|~/ansible/playbooks/ansible_grundconfig_v2.yml]]''** angelegt.
+   $ tree inventories/production/ -d
+<code>inventories/production/
+├── group_vars
+│   └── all
+└── host_vars</code>
+Je **Gruppe** speichern wir also eine individuelle Datei im Verzeichnis **''~/ansible/inventories/production/group_vars''** ab.
+   $ vim ~/ansible/inventories/production/group_vars/ffmuc.yml
+<file bash ~/ansible/inventories/production/group_vars/ffmuc.yml>ffmuc:
+  ansible_ssh_port: 22
+  ansible_ssh_user: root
+  ansible_ssh_private_key_file: /home/django/.ssh/id_rsa4096_freifunk_2014.pub
+  contact_info: 'Django [BOfH] | django@nausch.org | chat -> @django'
+</file>
+Für die anderen Gruppe(n) verfahren wie ebenso.
+Je **Host** speichern wir dann jeweils eine individuelle Datei im Verzeichnis **''~/ansible/inventory/hosts_vars''** ab.
+   $ vim ~/ansible/inventories/production/host_vars/ff_pliening_gbw_egod.yml
+<file bash ~/ansible/inventories/production/host_vars/ff_pliening_gbw_egod.yml>ff_pliening_gbw_egod:
+  hostname: ffplieninggbwegod
+  pretty_hostname: ff_pliening_gbw_egod
+  latitude: 48.198652080
+  longitude: 11.797969940
+  branch: stable
+  domain: ffmuc_muc_ost
+  director: ffmuc_muc_ost
+  modell: Ubiquiti UniFi-AC-MESH
+  ansible_ssh_host: 2001:608:a01:102:1ae8:29ff:fea9:22ed</file>
+Auch für die anderen Hosts legen wir entsprechende Dateien mit den Variablen an.
+=== Zusammenfassung ===
+Nun haben alle unsere eigenen definierten Freifunk Knoten haben nun auf der **[[https://map.ffmuc.net/#!/de/map/18e829a922ed|Freifunk München Karte]]** die aktualisierten GeoDaten. Zum anderen ist der Administrative Aufwand entsprechend überschaubar, so könnte man erst einmal den Stand der "Ermittlungen" zusammenfassen.
+<WRAP center round info 80%>
+Zum Thema administrativer Aufwand wollen wir uns kurz noch ein kleines Rechenbeispiel ansehen. Nehmen wir mal an, wie hätten eine etwas grössere Installation mit folgenden Eckdaten:
+  * **145** Zeilen (ohne Variablen):
+    * mit **76** Hosts
+    * und **13** Unter-/Gruppen
+Bei durchschnittlich 15 Variablen pro Host und 5 Variablen pro Gruppe ergäbe das eine Inventory-Datei mit
+  * **145** Zeilen (ohne Variablen): 145
+    * mit **76** Hosts ~15 Variablen pro Host: 1.140
+    * und **13** Unter-/Gruppen ~5 Variablen je Gruppe: 65
+ergäbe dies eine Inventory-Datei mit **__1.350__** Zeilen. 8-o
+Wir sehen, dass sich die Pflege hier doch sehr schnell zu einer doch erheblichen Herausforderung auswachsen wird! Ein weiteres Thema ist, dass YML-Files bedingt durch Ihre Struktur zwar für den Menschen recht gut zu lesen und auch zu bearbeiten sind. \\
+**__Aber__** wenn man solch eine Datei aus einer **CMDB** automatisiert erzeugen möchte, klappt dies schon nicht mehr so einfach, wie anfänglich angenommen. Wir werden uns daher im nächsten Beispiel eine doch geeignetere Variante ansehen.
+</WRAP>
+==== CMDB-basierte professionelle Umgebungen ====
+Wie schon im vorhergehenden Beispiel angemerkt, wird es zum einen bei professionellen Umgebungen, nicht mehr praktikabel pflegbar sein, alle Informationen in einer YML-Datei mit verschiedenen Host- oder Gruppen basierenden Variablen-Definitionen versuchen vor zuhalten. Der Export und das automatische Generieren von Inventory-Daten in strukturierter **''bash''**-Notation eignet sich hier wesentlich besser!
+Bei der Grundkonfiguration unserer Ansible-Umgebung mit Hilfe des Ansible-Playbooks **''[[playbook_example_08#aufgabenstellung_2_-_erweiterte_grund-_basis-installation_fuer_ansible-vault|~/ansible/playbooks/ansible_grundconfig_v2.yml]]''** wurde bereits das entsprechend benötigte  **[[first#ansibledirectory_layout|Ansible: Directory Layout]]** automatisch angelegt.
+<code>inventories/production/
+├── group_vars
+│   └── all
+└── host_vars</code>
+Wir können nun entweder eine Inventory-Datei **''hosts''** im betreffenden Verzeichnis manuell anlegen oder eben aus unserer **CMDB** scriptiert erstellen lassen. Nachfolgend sehen wir, wie solch eine Inventory Datei aufgebaut und strukturiert sein könnte. Das exemplarische Beispiel ist hier entsprechend gekürzt und die Stellen mit Hilfe von **''%%...%%''** markiert wiedergegeben"
+   $ less ~/ansible/inventories/production/hosts
+<file bash hosts># Generiert mit Hilfe von Ansible am 2022-09-20 - diese Datei nicht manuell bearbeiten!
+# Inventory Datei für die System-Umgebung bei nausch.org
+#
+# Hinweise:
+#           Kommentare beginnen mit einem '#'-Zeichen
+#           leere Zeilen werden ignoriert
+#           Host- und Gruppendefinitionen werden mit [] abgegrenzt
+#           Hosts können über ihren Hostnamen, FQN oder ihrer IP-Adresse definiert
+#           übergeordnete Gruppen werden durch [:children] abgegrenzt
+#
+# Host-Definitionen
+# Hosts ohne Gruppenzuordnung
+localhost
+[intranet]
+pml010002
+pml010003
+pml010004
+...
+...
+pml010124
+pml010125
+pml010126
+[IDMZ]
+vml030010
+vml030020
+vml030030
+vml030040
+...
+...
+vml030230
+vml030240
+vml030250
+[EDMZ]
+vml050010
+vml050020
+vml050030
+vml050040
+vml050250
+[TKDMZ]
+vml070010
+vml070020
+vml070030
+[external]
+customer_no_001
+customer_no_002
+...
+...
+customer_no_042
+[gluon]
+ff_pliening_gbw__ug_
+ff_pliening_gbw_egod
+ff_pliening_gbw_ogod
+ff_pliening_gbw_dgod
+ff_pliening_gbw_cpod
+ff_roding_fwg_nausch
+[raspbian]
+ff_pliening_rpb4_ol_v6
+# Host-Gruppen-Definitionen
+# (zu welcher Gruppe gehören Untergruppen bzw. Hosts)
+[freifunk:children]
+gluon
+raspbian
+[linux:children]
+intranet
+IDMZ
+EDMZ
+TKDMZ
+external
+</file>
+Die betreffenden Host- bzw. Gruppenspezifischen Variablen halten wir hier in entsprechenden Dateien bzw. Unterverzeichnissen vor, wie z.B. die automatisch erzeugte Datei **''ansible_environment.ym''** mit den Ansible Konfiguration zur Rechteerweiterung.
+   $ less inventories/production/group_vars/all/ansible_environment
+<file c++ ansible_environment># Generated by Ansible on 2022-09-22, do not edit manually!
+ansible_become: True
+ansible_become_method: sudo
+ansible_become_user: root
+ansible_become_ask_pass: False</file>
+Oder z.B. die Definitionen für eine bestimmte Gruppe.
+   $ less inventories/production/group_vars/IDMZ/ssh_environment
+<file c++ ssh_environment># Generated by Ansible on 2022-09-22, do not edit manually!
+ssh_port: 22
+ssh_user: django
+ssh_protocol: 2
+ssh_keyfile: ~/.ssh/id_idmz</file>
+Das Beispiel hier zeigt die Host-spezifischen Variablen eines Hosts im Intranet.
+   $ less inventories/production/host_vars/pml111002
+<file c++ pml111002># Generated by Ansible on 2022-09-20, do not edit manually!
+host_alias: printer
+host_mac: "84:3a:de:ad:be:ef"
+host_ipv4: "10.111.0.2"
+host_ipv6: "::1"
+host_sshjump: "vml070010"</file>
+Unser Inventory hat nun in etwa nachfolgenden strukturellen Aufbau, bei dem auch wieder die entsprechend gekürzt und die Stellen mit Hilfe von **''%%...%%''** markiert wurden.
+<code>inventories/production/
+├── group_vars
+│   ├─── all
+│   |   ├── ansible_environment
+│   |   ├── ssh_environment
+│   |   └── vault
+|   ├─── IDMZ
+|   |   └── ssh_environment
+|   ├─── EDMZ
+|   |   └── ssh_environment
+|   ├─── TKDMZ
+|   |   └── ssh_environment
+|   └─── external
+│       ├── ssh_environment
+|       └── vault
+├── hosts
+└── host_vars
+    ├── ff_pliening_gbw_cpod
+    ├── ff_pliening_gbw_dgod
+    ├── ff_pliening_gbw_egod
+    ├── ff_pliening_gbw_ogod
+    ├── ff_pliening_gbw__ug_
+    ├── ff_pliening_rpb4_ol_v6
+    ├── ff_roding_fwg_nausch
+    ├── pml111002
+    ├── pml111003
+    ├── pml111004
+...
+...
+    ├── pml010124
+    ├── pml010125
+    ├── pml010126
+    ├── vml030010
+    ├── vml030020
+    │   ├── dhcpd
+    │   ├── named
+    │   └── hostconfig
+    ├── vml030030
+    ├── vml030040
+...
+...
+    ├── vml030230
+    ├── vml030240
+    ├── vml030250
+    ├── vml050010
+    ├── vml050020
+    │   ├── vhosts
+    │   └── hostconfig
+    ├── vml000030
+    │   ├── exporter
+    │   ├── github
+    │   └── hostconfig
+    ├── vml050030
+    ├── vml050040
+    │   ├── prometheus
+    │   ├── grafana
+    │   ├── apache
+    │   └── hostconfig
+    ├── vml050250
+    ├── vml070010
+    ├── vml070020
+    ├── vml070030
+    ├── customer_no_001
+    ├── customer_no_002
+...
+...
+    └── customer_no_002
+</code>
+=== Zusammenfassung ===
+<WRAP center round tip 80%>
+Wir haben nun eine standardisiertes Inventory. Die hilft uns zum einen bei der ggf. manuellen Pflege, da Informationen strukturiert immer an definierten Stellen stehen. Dies verlangt natürlich den Admins einiges an Disziplin ab, aber so können sich alle darauf verlassen, dass benötigte Informationen und Konfigurationsoptionen an den gleichen Stellen stehen (sollten).
+Pflegt man die Inventory-Daten hingegen über eine (WEB)UI einer CMBD-Anwendung und generiert dann automatisiert die entsprechenden Inventory-Daten, ist dann auch sicher gestellt, dass alle Daten wirklich gleich strukturiert und an den vorgesehenen Stellen stehen. Wie das von Statten geht, werden wir uns später noch eingehender ansehen.
+</WRAP>
-===== lorem ipsum dolor sit amet =====
-:KRIT: FIXME :KRIT:
+====== Links ======
+  * **[[detail|zurück zum Kapitel "Ansible - Erweiterte Konfigurationsbeispiele"]] <= **
+  * **=> [[playbook_example_10|weiter zum Kapitel "Ansible Controll Node]]**
+  * **[[start|Zurück zur "Ansible"-Übersicht]]**
+  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
+  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**