P-I-DO_Automatisierung_Backup_Switches.pdf

TF Bern - Projekt-Dokumentation 5. Juni 2023 1 / 23
Projekt Dokumentation
Projekt-Daten
Projektname Automatisiertes Switch Backup
Autor Fachgruppe Netzwerk
Abteilung Informatik und Elektronik
Fachrichtung BET
Projektvorgehensmodell TFBern (nach Hermes)
Beteiligter Personenkreis
Berufsbildner Matthias Heimberg
Projektleiter Matthias Heimber
Fachspezialist Andre Delgado Goncalves, Jannic Flückiger
Tester Andre Delgado Goncalve
Benutzer, Anwender Technische Fachschule Bern
Kommentiert [HM1]: Tabelle ergänzen
Kommentiert [JF2R1]: Done
hat formatiert: Englisch (Vereinigte Staaten)

1 Kurzbeschreibung des Projektes
1.1 Kurze Ausgangssituation
Aktuell werden die Konfigurationen über ein einzelnes Python Skript gespeichert, dies ist nicht
optimal und kann nicht gut überwacht werden, auch werden nur zwei von 6 Switches gesichert, und
diese Konfigurationen werden auch nicht in die dafür vorgesehen einzelnen Switch Repositorys
gesichert. Auch werden bei Fehlern noch keine Benachrichtigungen versendet
1.2 Umsetzung
Die Umsetzung des Projekts erfolgte in Form einer Pipeline, der Code wurde in vier Stages unterteilt:
1. Pull: In dieser Stage wird die Konfiguration des jeweiligen Switches abgerufen.
2. Check-config: Hier wird überprüft, ob sich die Konfiguration seit der letzten Überprüfung
geändert hat.
3. Push: In der Push-Stage wird die geänderte Konfiguration in das zentrale Repository unter
https://git.it-tf.ch/infrastruktur-abteilung-i/netzwerk/netzwerkger-t-konfigurationen mittels
Commit und Push hinterlegt.
4. Check-repo: Die letzte Stage prüft, ob die geänderte Konfiguration erfolgreich im Repository
gespeichert wurde.
1.3 Ergebnis
Durch die erfolgreiche Umsetzung dieses Projekts wurde ein automatisierter Prozess etabliert, der
täglich die Konfigurationen der sechs Switches überprüft. Bei Änderungen werden die neuen
Konfigurationen im zentralen Repository gesichert. Sollte eine Sicherung fehlschlagen, wird die
Fachgruppenleitung umgehend per E-Mail informiert. Sobald nun ein funktionierender GitLab Runner
eingerichtet wird ist das System lauffähig-

2 Inhaltsverzeichnis
1 Kurzbeschreibung des Projektes .................................................................................................... 2
1.1 Kurze Ausgangssituation ........................................................................................................ 2
1.2 Umsetzung .............................................................................................................................. 2
1.3 Ergebnis................................................................................................................................... 2
2 Inhaltsverzeichnis ........................................................................................................................... 3
Teil 2: Projektdokumentation ................................................................................................................ 4
3 Initialisierung .................................................................................................................................. 4
3.1 Ist-Zustand .............................................................................................................................. 4
3.2 Soll-Zustand ............................................................................................................................ 4
3.3 Projektziele ............................................................................................................................. 4
4 Konzept ........................................................................................................................................... 6
4.2 IP-Konzept............................................................................................................................... 8
4.3 VM-Konzept ............................................................................................................................ 9
4.4 Einführungskonzept.............................................................................................................. 10
4.5 User Konzept......................................................................................................................... 13
4.6 Testkonzept........................................................................................................................... 14
5 Realisierung................................................................................................................................... 17
5.1 Code in vier Phasen gliedern................................................................................................ 17
5.2 Repository für jeden Switch einrichten ............................................................................... 17
5.3 Switch Einrichten und Backup User erstellen...................................................................... 17
5.4 E-Mail-Benachrichtigungen einrichten ................................................................................ 17
5.5 Testprotokoll......................................................................................................................... 18
6 Tabellenverzeichnis ...................................................................................................................... 21
7 Abbildungsverzeichnis.................................................................................................................. 21

Teil 2: Projektdokumentation
3 Initialisierung
Die Initialisierung dient dazu, die Ausgangslage des Projekts zu analysieren. Weiter soll festgelegt
werden, was mit dem Projekt erreicht werden soll, wie also das Endresultat aussehen soll. Ein
weiteres wichtiges Element der Initialisierung ist der Variantenentscheid.
3.1 Ist-Zustand
Das Skript, um die Backups der Switches zu machen ist aktuell nur eine Code-Datei , dieses Programm
soll auf vier Stages unterteilt werden um es in einer GitLab CI/CD Pipeline laufen zu lassen. Auch
macht das Programm aktuell nur von zwei Anex Switches den Switches LOA904_SW01 und
LOA002_SW05_UK Backups und es werden alle Backups im selben Repository wie der Code
gespeichert, was auch geändert werden soll.
3.2 Soll-Zustand
Das Projekt "Konfigurationsüberprüfung der Switches" soll sicherstellen, dass die Konfigurationen der
genannten Switches LOA904_SW01, LOA002_SW05_UK, LOA002_ST01, LOH301_SW01,
LOH306_SW01 und LOH312_SW01 Täglich auf Änderungen überprüft werden. Um dieses Ziel zu
erreichen, soll der aktuelle Code auf vier CI/CD stages unterteilt werden. Es ist erforderlich, eine
Pipeline zu implementieren, die in der Lage ist, automatisch Konfigurationsänderungen zu erkennen
und in das Repository des entsprechenden Switches zu speichern. Darüber hinaus sollte die
Fachgruppe Netzwerk per E-Mail benachrichtigt werden, wenn eine Sicherung fehlschlägt.
3.3 Projektziele
Hier werden die Projektziele beschrieben.
Ziel ID Ziel Beschreibung
Z1 Die Konfiguration aller
Produktiven Switches werden
gebackupt um die Funktion der
Switches bei einem Verlust der
Konfiguration der Switches
wiederherstellen zu können
Die Konfigurationen müssen, um sie zu vergleichen
zuerst von den Switches geholt und
zwischengespeichert werden.
Z2 Änderungen an den
Konfigurationen können
nachvollzogen werden.
Die Konfigurationen werden von Git geholt um sie mit
den Frischen Switch Konfigurationen zu vergleichen.
Tabelle 1: Projektziele
Kommentiert [HM3]: Wo finde ich diese? -> Anhang
Kommentiert [HM5]: Welche genau?
Kommentiert [HM7]: Wo werden diese beschrieben?
Kommentiert [HM9]: Ziele sind auf einer höheren Ebene: Z.Bsp.
könnte ein Ziel sein, dass die Patchliste immer aktuell ist und dass
eindeutig nachvollzogen werden kann wer wann welche Teile davon
verändert hat (Integrität)

3.4 Anforderungen
3.4.1 Funktionale Anforderungen
Anf. ID Ziel ID Anforderung Beschreibung
FA1 Z1 Tägliche Überprüfung
auf geänderte
Konfigurationen
Die Pipeline überprüft mindestens einmal pro Tag
alle Konfigurationen der Switches auf
Änderungen (diese Anforderung ist konkret und
messbar)
FA2 Z2 Nur geänderte
Knfigurationen werden
erfasst
Das System holt und vergleicht Konfigurationen
von Git und Switches. Bei Unterschieden werden
diese auf dem Switch-Repository mit einer
Commit-Nachricht aktualisiert. Nur geänderte
Konfigurationen werden bearbeitet, was
Ressourcen optimiert.
FA3 Z3 Wenn Änderungen
gemacht worden sind,
wird die neue
Konfiguration
gepushtPush geänderter
Konfigurationen
Wenn das Programm eine Änderung erkennt,
wird die neue Konfiguration mit einer Commit
Message auf das Repository des Switchs gepusht
FA4 Z4 Es wird eine Kontrolle
durchgeführt zum
Schauen, ob die
Konfiguration wirklich
gepusht wurde.Kontrolle
des Pushs
Nach dem dass die Konfiguration ins Git gepusht
wurde, wird erneut überprüft, ob der Ppush
korrekt funktioniert hat und die Konfiguration im
Git gespeichert wurde.
Tabelle 2: Funktionale Anforderungen
3.4.2 Nicht funktionale Anforderungen
Anf. ID Ziel ID Anforderung Beschreibung
NFA1 Z1 GitLab runner Es muss ein GitLab -runner erstellt werden.
Tabelle 3: Nicht Funktionale Anforderungen
Formatierte Tabelle
hat formatiert: Schriftfarbe: Text 1
Kommentiert [HM11]: FA2 und FA3 lassen sich
zusammenfassen: Nur geänderte Knfigurationen werden erfasst
Formatierte Tabelle
hat formatiert: fontstyle01, Schriftart: +Textkörper (Calibri),
11 Pt.
Kommentiert [HM13]: Schriftart?
hat formatiert: fontstyle01
Kommentiert [HM15]: Einheitliche Schreibweise verwenden:
GitLab-Runner

4 Konzept
4.1.1 System Diagramm
In Abbildung 1 ist der Ablauf innerhalb des Systems in der ersten Stage als Beispiel dargestellt:
1. GitLab Pipeline: Die Pipeline ist in vier Stages aufgeteilt und schickt die Codes von jeder Stage
zum GitLab-Runner, in diesem Fall der Code der ersten Stage und am Schluss speichert er die
neuen Configs ab.
2. GitLab -runner: Der GitLab -runner führt die Codes aus, in diesem Fall fragt und liest der
GitLab-Runner die Configs der Switches ab.
Zusammenfassend sind die Konfigurationsdateien auf Git gespeichert und werden dann durch
die Pipeline an den GitLab -runner geschickt und dort werden die Codes schlussendlich
ausgeführt.
Abbildung 1 System Diagramm
Kommentiert [HM17]: Es fehlen die folgenden Elemente:
-Konzept der Pipeline (hier bietet sich ein Diagramm an): In
welcher Stage wird was gemacht, welche Informationen werden
wo benutzt, wie verläuft die Kommunikation zu den Switches, wo
werden die Konfigurationen abgespeichert, wie wird mit Fehlern
umgegangen, usw.
-Systemübersicht (Diagramm)
-Einbettung in Umsysteme
-Netzwerkdiagramm

4.1.2 Pipeline Ablaufdiagramm
In Abbildung 2 wird der Ablauf der Pipeline dargestellt und die vier Stages gezeigt wie auch erklärt:
1. Erste Stage (Pull): Die erste Stage liest die Configs aus dem Switch aus.
2. Zweite Stage (check-config): Die zweite Stage vergleicht die momentane Configs der Switches und die Configs von Git.
3. Dritte Stage (push): Die dritte Stage pusht die Änderungen ins Git, falls Änderung gemacht wurden.
4. Vierte Stage (check-repo): Die vierte Stage kontrolliert, ob die Configs richtig gepusht wurden.
Abbildung 2 Pipeline Ablaufdiagramm
Kommentiert [HM18]: Grafik unten zu klein, man kann den
Text nicht lesen
Kommentiert [DGA19R18]: Done

4.1.3 Physikalischer Netzwerkplan
In Abbildung 3 wird der Physikalischer Netzwerkplan dargestellt:
Abbildung 3 Physikalischer Netzwerkplan
4.2 IP-Konzept
Die Tabelle 5 zeigt die IPv4-Adressen der Netzwerkkomponenten, die in dem Projekt zusammen
interagieren werden.
Name Netz IPv4-Adresse Beschreibung
GS-VS01 VLAN105 192.168.10.75 GitLab Server
LOA002-ST01 VLAN105 192.168.10.9 Switch
LOA002-SW05-UK VLAN105 192.168.10.6 Switch
LOA904-SW01 VLAN105 192.168.10.7 Core Switch
LOH301-SW01 VLAN105 192.168.10.4 Switch
Kommentiert [HM20]: es fehlen: GitLab, GitLab runner

Tabelle 4: IP-Konzept von Switches
4.3 VM-Konzept
4.3.1 GitLab-Runner
Die Tabelle 6 zeigt die Eigenschaften des Servers, der im Projekt implementiert werden soll.
Name Beschreibung
Code-RunnerGitLab -runner Als Runner wird ein GitLab runner verwendet.
Version v15.11.0
Speicherplatte 30GB Speicherplatz reichen für das Betriebssystem
und andere Daten
Prozessor Der Runner braucht Prozessor Leistung, 2 Kerne
sind genug, dies wurde in anderen Projekten wie
dem Projekt «Wir benötigen 2 Gitlab Runner»
bereits festgelegt.
Arbeitsspeicher Damit der Runner richtig funktioniert wird
genügend Arbeitsspeicher benötigt, daher braucht
er 18 GB
Tabelle 5: Eigenschaften des Code-RunnerGitLab -runners
Kommentiert [HM21]: Code-Runner ist etwas anderes
Kommentiert [HM23]: Das selbe hier

4.4 Einführungskonzept
Beschreibung
Das Einführungskonzept beschreibt die Massnahmen und Organisation für die Einführung.
Dazu gehören auch die Analyse und Planung der Massnahmen des Organisations-Change-
Managements zur Unterstützung des Übergangs vom alten Zustand zum neuen. Im
Einführungskonzept werden ebenfalls das Vorgehen für die Abnahme geregelt sowie die
Abnahmekriterien festgelegt.
Kommentiert [HM25]: Da fehlen noch wesentliche Teile, vgl.
zum Bsp.
https://www.hermes.admin.ch/de/projektmanagement/verstehen/
ergebnisse/einfuhrungskonzept.html

1 Ausgangslage
Beschreibung der Ausgangslage für das Einführungskonzept, Hinweis auf die Studie und auf die
gewählte Lösung.
2 Betroffenheitsanalyse
Analyse der Auswirkungen von Veränderung auf die Organisation, bzw. auf die Stakeholder
dient zur Festlegung von Massnahmen, um das Projekt in das richtige Licht zu rücken. Für jeden
Stakeholder wird ermittelt, wie er durch das Projekt tangiert wird, oder, wie das Projekt durch
ihn beeinflusst werden kann:
• die Einstellung und Interessen der Stakeholder
• die Art und Weise der Betroffenheit
• der Grad, bzw. die Intensität der Betroffenheit
• Stellung und Macht des Stakeholders im Projekt, bzw. in Rahmen der eingeführten
Anwendung
3 Einführungsvorgehen
Beschreibung des Vorgehens
• Einführungsstrategie, z.B. Stichtag oder stufenweise (Gebietsweise, Funktionale Staffelung,
Benutzergruppen etc.)
• Beschreibung der Übergangsphase und der Übergangsregelung
4 Einführungsmassnahmen
4.1 Organisations-Transition /-Changemanagement
• Massnahmen zur Überführung vom alten in den neuen Zustand der Organisation
• Massnahmen zur Unterstützung in der Umstellungsphase
• Informationskonzept (Hinweis auf Kommunikationsplan im Projektmanagementplan)
• Ausbildungskonzept mit Ausbildungszielen, Ausbildungsinhalte, Drehbuch, Trainer,
Ausbildungsunterlagen, Ausbildungsinfrastruktur,
• Übergangsregelungen vom bestehenden in den neuen Zustand
4.2 Notfallmassnahmen und Notfallorganisation
Massnahmen und Organisation für den Krisenfall während der Phase Einführung
5 Einführungsorganisation
Unterstützende Rollen für die Einführung (z.B. Einführungsverantwortliche, Superuser)
6 Einführungsplanung
• Grobplanung mit Meilensteinen
• Detailplanung

• Hinweis auf Arbeitsaufträge
7 Planung der Vorabnahme und der Abnahme
Vorgehen, Abnahmeorganisation (Rollen, Verantwortlichkeiten)
8 Abnahmekriterien
• Die Konfigurationen der folgenden Switches wird täglich auf Änderungen überprüft:
o LOA002-ST01
o LOA002-SW05-UK
o LOA904-SW01
o LOH301-SW01
o LOH306-SW01
o LOH312-SW01
• Bei einer geänderten Konfiguration wird diese in das Repository des Switches unter
https://git.it-tf.ch/infrastruktur-abteilung-i/netzwerk/netzwerkger-t-konfigurationen (einige
müssen hier noch erstellt werden) gesichert
o Jede Sicherung wird mit einem Commit versehen. Die Commitmessage ist nach
folgendem Muster aufgebaut: "Sicherung der Konfiguration am <03.05.2023> um
<23.43> Uhr"
o Schägt eine Sicherung fehl, wird die Fachgruppe Netzwerk per Mail informiert.
• Die Pipeline wird in die folgenden Stages unterteilt:
o pull (holt die Konfiguration des Switches)
o check-config (überprüft ob sich die Konfiguration geändert hat)
o push (wird nur ausgeführt wenn die Konfiguration geändert wurde, commit & pusht
die geänderte Config in das Repo)
o check-repo (wird nur ausgeführt wenn die Konfiguration geändert wurde, prüft, ob
die geänderte Konfiguration im Repository hinterlegt ist)

4.5 User Konzept
Im User Konzept sieht man Die Users die vom Projekt verwendet werden und wofür diese benutzt
werden.
Name Berechtigungsstuffe Beschreibung Standorte
Backupsvc 15 Service-Account für
Backups der Switches
LOA904_SW01
LOA002_SW05_UK
LOA002_ST01
LOH301_SW01
LOH306_SW01
LOH312_SW01
Tabelle 6: Backupsvc User
Formatierte Tabelle
Kommentiert [HM26]: Gilt diese Stufe für alle Switches?

4.6 Testkonzept
Im Testkonzept wird definiert, welche Tests in welchem Rahmen durchgeführt werden.
4.6.1 Testrahmen
Bevor angefangen wird zu testen, müssen bestimmte Voraussetzungen erfüllt sein. Als erstes muss
das Testkonzept ausgearbeitet sein. Die Realisierung muss schon abgeschlossen sein, damit die Tests
durchgeführt werden können.
Die Tester bekommen jeweils ein Testprotokoll, welches sie ausfüllen müssen, wobei sie die Tests in
vier Klassen einteilen. Die Klassen sind wie folgt:
ID Mangel ausmass Beschreibung
M1 Kein Mangel Hat keine Mängel vorzuweisen.
M2 Unwesentlicher Mangel
Der Mangel beeinträchtigt die Funktionalität nicht,
wird
dennoch mit dem Administrator besprochen.
M3 Kleiner Mangel
Der Mangel beeinträchtigt die Brauchbarkeit und kann
störend
sein, jedoch funktioniert das System.
M4 Grosser Mangel
Das System ist funktionsfähig, aber nicht in vollem
Ausmass und
mit vielen Fehlern.
Tabelle 7 Testrahmen
4.6.2 Testvorgehen
Als erstes wird geprüft, ob die Configs der Switches geholt werden. Danach wird geschaut, ob die
momentane Configs anders, als die Configs die auf dem Git gespeichert sind, sind. Falls Änderungen
stattfinden, werden die ins Git gepusht.
4.6.3 Testmethode
Bei der Testmethode werden System bzw. manuelle Tests durchgeführt.
4.6.4 Testziele
ID Name Beschreibung
1 Funktionalität Test sollte funktionieren und ein positives Ergebnis haben
Configs werden
aus dem Switch
geholt
Die Konfigurationsdateien werden aus dem Switch extrahiert, um die
aktuellen Einstellungen und Parameter zu erhalten.
Configs werden
verglichen.
Die abgerufenen Konfigurationen werden mit den vorhandenen verglichen,
um Unterschiede oder Änderungen zu erkennen.
Bei Änderungen
werden configs
ins Git gepusht.
Wenn Änderungen festgestellt werden, werden die neuen Konfigurationen
ins Git-Repository gepusht, um eine zentrale Ablage und Versionierung zu
ermöglic
Kontrolle, ob die
Config tatsächlich
gepusht wurde.
Es erfolgt eine Überprüfung, ob der Push-Vorgang erfolgreich war, um
sicherzustellen, dass die Konfigurationen ordnungsgemäß im Git-Repository
gespeichert wurde
Kommentiert [HM29]: Viel zu allgemein
Kommentiert [HM28]: Zu allgemein
Bessere Ziele wären z.Bsp.:
Die Pull Stage soll ohne Fehler ausgeführt werden und die
erwarteten Konfigurationsdateien herunterladen.
Der Inhalt des config-Verzeichnisses sollte nach der Ausführung von
pull_config.py korrekt aufgelistet werden.
Die Pipeline sollte korrekt ausgelöst werden, wenn sie geplant ist
($CI_PIPELINE_SOURCE == "schedule").
Usw.

2 Fehler Wenn ein Fehler bestehen sollte, sollte der Fehler verbessert werden
solange dies mit den Zeitressourcen vereinbar ist
Tabelle 8 Testziele

4.6.5 Tests
Testfall-Nr. 1
ID FA1
Name Configs werden aus dem Switch geholtTest der Pull-Stage
Beschreibung Die Configs aus dem Switch müssen ausgelesen werdenDas Skript
pull_config.py der Pull Stage wird auf korrekte Funktionalität geprüft
Testvoraussetzung • Zugang zum Repository unter https://git.it-tf.ch/infrastruktur-
abteilung-i/netzwerk/netzwerkger-t-konfigurationen/backup-
pipelinem Git mit der Berechtigung die CI/CD-Pipeline auszuführen
• Zugang zu Switchesden Switches <hier verweisen auf den Abschnitt in
welchem die Switches beschrieben werden (fehlt noch)>
Testvorgehen: 1. Auf «Git.it-tf.ch» gehen
2.1.Auf den Backup-Pipeline Repository gehenDas Repository unter
https://git.it-tf.ch/infrastruktur-abteilung-i/netzwerk/netzwerkger-t-
konfigurationen/backup-pipeline in einem Browser öffnen
3.2.In der Navigationsleiste linksLinks auf «CI/CD» drücken auswählen und
dann oben rechts auf «Run pipeline» klicken
4.3.Auf die erste Stage achten
Erwartetes Resultat: Die Configs der Switches werden ausgelesen
Tabelle 9 Testfall
Testfall-Nr. 2
ID FA2
Name Configs werden verglichen
Beschreibung Die derzeitigen Configs des switches werden mit den Configs von Git
verglichen.
Testvoraussetzung • Zugang zum Git
• Zugang zu Switches
2. Auf den Backup-Pipeline Repository gehen
3. Links auf «CI/CD» drücken und dann oben rechts auf «Run pipeline»
klicken
4. Auf die zweite Stage achten
Erwartetes Resultat: Die Configs werden verglichen.
Tabelle 10 Testfall
Testfall-Nr. 3
ID-Anforderungen FA3
Name Falls Änderungen stattgefunden haben, werden diese ins Git gepusht.
Beschreibung Wenn Änderungen gemacht worden sind, wird die neue Datei gepusht
Kommentiert [HM30]: Überarbeiten:
Stellt euch vor, ihr gebt dies einem ICTler zum Testen. Welche
Informationen benötigt der, um die Tests durchführen zu können?
Wie kann er entscheiden, ob der Test ok ist?
Kommentiert [HM31]: Welches Ziel deckt der Testfall ab?
Kommentiert [HM32]: Das ist zu wenig präzise, was heisst
"achten"?
Im Job ist ja sinnvollerweise die Ausgabe des Verzeichnisses mit den
Configs eingebaut:
Der Test muss doch überprüfen, ob hier die notwendigen Dateien
angezeigt werden!
Kommentiert [HM33]: Am besten gleich einen Screenshot mit
dem erwarteten Resultat!
Kommentiert [HM34]: Bitte die restlichen Testfälle gemäss
dem ersten überarbeiten

klicken
4. Auf die dritte Stage achten
Erwartetes Resultat: Die Änderungen werden ins Git gepusht
Tabelle 11 Testfall
Testfall-Nr. 4
ID-Anforderungen FA4
Name Kontrolle, ob die Datei wirklich gepusht worden ist.
Beschreibung Es wird eine Kontrolle durchgeführt zum Schauen, ob die Datei wirklich
gepusht worden ist.
klicken
4. Auf die vierte Stage achten
Erwartetes Resultat: Die Dateien werden kontrolliert.
Tabelle 12 Testfall
5 Realisierung
5.1 Code in vier Phasen gliedern
Der Code welcher bereits existierte, bestand nur aus einer Datei, um jeden Teil des Codes als
einzelne Stufe in der CI/CD Pipeline laufen zu lassen, müssen alle Teile des Codes auf einzelne Files
aufgeteilt werden. Wir haben den Code in Folgende Stufen unterteilt: Pull_config, check_config,
push_config und check_repo, somit können wir besser auf Fehler Reagieren die eventuell auftreten.
5.2 Repository für jeden Switch einrichten
Bisher wurden alle Konfigurationen im selben Repository wie der Code gespeichert. Dies wurde
geändert, sodass nun jeder Switch ein eigenes Repository besitzt, in dem seine Config und
gegebenenfalls weitere Daten abgelegt werden. Die Repositorys heissen: LOA002-ST01, LOA002-
SW05-UK, LOA904-SW01, LOH301-SW01, LOH306-SW01, LOH312-SW01
5.3 Switch Einrichten und Backup User erstellen
Für jeden Switch wurde ein Benutzer namens "Backupsvc" eingerichtet, der für das Abrufen aller
Configs für die Backups verantwortlich ist. Einige Die Switches LOH312-SW01 und LOH301-
SW01mussten umkonfiguriert werden, sodass nach der Eingabe von "ssh user@ip" lediglich das
Passwort und nicht beide Anmeldeinformationen abgefragt werden. Dafür wurden die Befehle conf t
und ip ssh password-auth ausgeführt.
5.4 E-Mail-Benachrichtigungen einrichten
Der Code ist so konzipiert, dass eine Phase bei einem Fehler abbricht und ausgewählte Personen
benachrichtigt werden. Dafür wird ein Feature von GitLab verwendet.
Formatiert: Beschriftung, Abstand Nach: 0 Pt.,
Zeilenabstand: einfach
Kommentiert [HM35]: Ich kann nicht nachvollziehen, was da
gemacht wurde. Beschreibt die Sachen so, dass auch
Aussenstehende sehen, was ihr gemacht habt. Es muss alles
nachvollziehbar dokumentiert sein!
Kommentiert [HM36]: Wie lauten die repos?
Formatiert: Block
Kommentiert [HM38]: Welche?
Kommentiert [HM40]: Wie?
Kommentiert [HM42]: Wird das getestet?

5.5 Testprotokoll
Testfall-ID 1 Datum
Testmethode White Box 09.05.2023
Tatsächliches
Resultat
Die Configs werden ausgelesen.
Fazit des
Testers
Die Configs werden ausgelesen und somit kann es mit der zweiten Stage
weitergehen.
Fehlerklasse M1
Tabelle 13 Testprotokoll
Testfall-ID 2 Datum
Tatsächliches
Resultat
Die Configs werden verglichen.
Fazit des
Testers
Die Configs wurden erfolgreich verglichen und somit kann die dritte Stage
anfangen.
Fehlerklasse M1

Testfall-ID 3 Datum
Tatsächliches
Resultat
Die Änderungen werden gepusht.
Fazit des
Testers
Die Änderungen werden ins Git gepusht (wenn es Änderung gibt) und die letzte
Stage wird gestartet.
Fehlerklasse M1
Testfall-ID 4 Datum
Tatsächliches
Resultat
Die Kontrolle wird durchgeführt.
Fazit des
Testers
Es wird kontrolliert und bestätigt das die Datei gepusht wurde und somit kann die
Pipeline beendet werden.
Fehlerklasse M1

6 Tabellenverzeichnis
Tabelle 1: Projektziele ............................................................................................................................. 4
Tabelle 2: Funktionale Anforderungen.................................................................................................... 5
Tabelle 3: Nicht Funktionale Anforderungen.......................................................................................... 5
Tabelle 4: IP-Konzept von Switches......................................................................................................... 9
Tabelle 5: Eigenschaften des Code-RunnerGitLab -runners.................................................................... 9
Tabelle 6: Backupsvc User..................................................................................................................... 13
Tabelle 7 Testrahmen............................................................................................................................ 14
Tabelle 8 Testziele................................................................................................................................. 15
Tabelle 9 Testfall.................................................................................................................................... 16
Tabelle 10 Testfall.................................................................................................................................. 16
Tabelle 13 Testprotokoll........................................................................................................................ 18
7 Abbildungsverzeichnis
Abbildung 1 System Diagramm ............................................................................................................... 6
Abbildung 2 Pipeline Ablaufdiagramm.................................................................................................... 7
Abbildung 3 Physikalischer Netzwerkplan .........................................Fehler! Textmarke nicht definiert.
8 Anhang
Ursprünglicher Code:
import configparser
from netmiko import ConnectHandler
import gitlab
import os
gl = gitlab.Gitlab(url='https://git.it-tf.ch/',
private_token=os.environ['access_token_backup_switch'], ssl_verify=False)
gl.enable_debug()
gl.auth()
def get_switch_informations():
switch_informations = configparser.ConfigParser()
switch_informations.read("switches.ini")
return switch_informations
def get_config_switch_already_in_git(switch):
project = gl.projects.get('975')

file = project.files.get(file_path=f'{switch}.txt', ref='main')
switch_config_already_in_gitlab = file.decode()
return switch_config_already_in_gitlab
def save_config_switch(switch_config):
with open("switch_config.txt", "w+") as file:
file.write(switch_config)
file.seek(0)
return file.read()
def check_if_configs_are_the_same(new_config, git_config):
return True if new_config == git_config else False
def main():
switch_informations = get_switch_informations()
for switch in switch_informations.sections():
# save connection data
print("----------------------------------------------")
# get Connection data
device_params = {
'device_type': switch_informations[switch]['device_type'],
'ip': switch_informations[switch]['ip'],
'username': os.environ['USERNAME'],
'password': os.environ['PASSWORD'],
'secret': os.environ[f'SECRET_{switch}']
}
connection = ConnectHandler(**device_params)
print("Connection successful")
connection.enable()
print("enable successful")
switch_config = connection.send_command('show running-config',
read_timeout=60)
config_switch = save_config_switch(switch_config)
config_switch_already_in_gitlab =
get_config_switch_already_in_git(switch)
are_the_configs_the_same =
check_if_configs_are_the_same(config_switch, config_switch_already_in_gitlab)

if are_the_configs_the_same:
print("Die Konfigurationen sind gleich. Kein Push ist nötig")
else:
project = gl.projects.get('975')
file = project.files.get(file_path=f'{switch}.txt', ref='main')
file.content = config_switch
file.save(branch='main', commit_message='Config update')
main()

P-I-DO_Automatisierung_Backup_Switches.pdf

Recommended

Recommended

More Related Content

Similar to P-I-DO_Automatisierung_Backup_Switches.pdf

Similar to P-I-DO_Automatisierung_Backup_Switches.pdf (20)

Recently uploaded

Recently uploaded (8)

P-I-DO_Automatisierung_Backup_Switches.pdf