ubuntuusers.de

Hallo zusammen.

Ich verstehe es grad nicht und benötige mal bitte Eure Hilfe.

Ich habe hier ein ziemlich umfangreiches bash-Script, welches über mehreren Dateien verteilt ist, in Bearbeitung. Nun nimmt das solche Dimensionen an, dass eine "feste" Programmierung so langsam aber sicher unübersichtlich wird. Bisher sieht das (in gekürzter Form) so aus:

1
2
3
4
5
6
7
8

#!/usr/bin/env bash

main() {
  source init.sh
  source echo.sh
}

main

Es funktioniert und eigentlich ist alles gut. Jetzt möchte ich aber alle Scripte, weil es unübersichtlich wird, in einem Unterordner lagern. Die Veränderung funktioniert auch ohne Probleme, es ist ja "nur" ein neuer Pfad. Damit ich aber etwas flexibler werde und nicht jedes Mal das Hauptscript verändern muss, möchte ich das ganze etwas dynamischer machen. Neue Datei einfach einfügen und sie wird mit abgearbeitet. Also so:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#!/usr/bin/env bash

main() {
for file in eingabe/*.sh
do
 source $file
done
}

main

Das Script bricht mit der ersten Datei ohne Ausgabe eines Fehlers ab. Ersetze ich "source" durch echo, läuft es durch bis zum Ende, jede einzelne Datei wird angezeigt. Ich habe da wohl irgendwo einen Denkfehler, leider sehe ich grad den Wald vor lauter Bäumen nicht. Wo steckt mein Fehler?

Wenn er vorzeitig abbricht, würde ich mal in die Skripte schauen, ob da irgendwo exit Befehle ausgeführt werden - am besten mal in der zweiten Zeile des Skripts ein set -x einfügen, dann sieht man was für Schritte er durchläuft.

Mit einer Process Substitution könnte man auf die for-Schleife verzichten (alle Pfade, die auf den Glob passen, müssen lesbare Dateien sein):

1
2

#!/bin/bash
source <(cat eingabe/*.sh)

Danke, die Idee mit dem Verkürzen ist auch nicht schlecht.

Der Fehler lag jedoch ganz woanders. Eine Datei mit dem Namen "ende.sh" wird natürlich immer vor funktion.sh oder query.sh oder xy.sh aufgerufen. Und wenn in der Datei "ende.sh" ein exit 0 steht, nun dann macht das Script natürlich auch, es beendet sich.

Ich hole mir jetzt mal meine mobile Tischplatte und werfe sie mir an den Kopf.

Danke und Sorry ... das mit den Bäumen und dem Wald, ich wusste es. ...

Zum Tracen packe ich immer folgende Zeile an den Anfang des Skriptes:

1

test -z "$DEBUG" || set -x

Dann kann man einen ganzen Satz von Skripten so tracen:

1

$ DEBUG=x script

Warum hast Du denn das Skript auf mehrere Dateien aufgeteilt? Wenn Du die Teile nicht mehrfach in anderen Skripten einbinden willst, ist die Sache ggf. einfach zu handhaben, wenn alles in einer Datei ist.

Danke, auch eine Idee. Ich werde es mal versuchen damit.

Der Grund weswegen ich die Dateien aufsplitte ist, dass das eine Script so langsam unübersichtlich geworden ist. Genau genommen ist es mein Firewall-Script, dass inzwischen auf weit über 500 Zeilen angewachsen ist. Und um da wieder etwas Übersicht hinein zu bringen, habe ich für jedes Regelset eine eigene Datei angelegt. Teils sind es sogar diverse Netzwerkgeräte, die ein eigenes Regelset besitzen. Inzwischen erschien mir das aber nicht gut genug, da ich die Flexibilität schätze, ohne im Hauptscript jedes mal Änderungen bzw. Ergänzungen machen zu müssen. Zudem ist es inzwischen auf verschiedenen Routern mit teils sehr unterschiedlichen Konfigurationen aktiv. Updates und Änderungen am Hauptscript waren somit immer sehr aufwändig und oft fehleranfällig.

Wenn das ganze läuft wollte ich es sowieso auf github veröffentlichen. Dann wird sich sicher automatisch erklären, weswegen ich diesen Weg gewählt. habe. ;o)

Wutze schrieb:

Der Grund weswegen ich die Dateien aufsplitte ist, dass das eine Script so langsam unübersichtlich geworden ist. Genau genommen ist es mein Firewall-Script, dass inzwischen auf weit über 500 Zeilen angewachsen ist.

Oh. Wenn man so viele Feuerwandregeln hat, dann wird es natürlich leicht mal unübersichtlich. So etwas kann auch ein Sicherheitsproblem sein.

Und um da wieder etwas Übersicht hinein zu bringen, habe ich für jedes Regelset eine eigene Datei angelegt. Teils sind es sogar diverse Netzwerkgeräte, die ein eigenes Regelset besitzen. Inzwischen erschien mir das aber nicht gut genug, da ich die Flexibilität schätze, ohne im Hauptscript jedes mal Änderungen bzw. Ergänzungen machen zu müssen. Zudem ist es inzwischen auf verschiedenen Routern mit teils sehr unterschiedlichen Konfigurationen aktiv. Updates und Änderungen am Hauptscript waren somit immer sehr aufwändig und oft fehleranfällig.

Dann macht es natürlich Sinn, den Teil, der gemeinsam ist, zu zentralisieren und die gerätespezifische Logik auszulagern.

Wenn das ganze läuft wollte ich es sowieso auf github veröffentlichen. Dann wird sich sicher automatisch erklären, weswegen ich diesen Weg gewählt. habe. ;o)

Ja, da bin ich gespannt.

So, was lange währt wird gut, oder so.

Das "Script", wenn man das noch so sagen darf, ist so weit erst mal fertig und auch getestet. Es läuft eigentlich ohne Probleme, wurde am Ende nur ein klein wenig umfangreicher als gedacht. Aber jetzt deckt es meines Erachtens nach alles ab was man möchte.

Wer mag kann ja hier mal rein sehen

https://github.com/Wutze/firewall

Die Doku ist noch nicht ganz beendet, für den ersten Blick und Verständnis sollte es aber genügen, denke ich. Wird auf jeden Fall noch weiter entwickelt, so ich die Zeit dazu finde.

Viel Spaß

Wutze schrieb:

So, was lange währt wird gut, oder so.

☺

Wer mag kann ja hier mal rein sehen

https://github.com/Wutze/firewall

Ein paar völlig unsortierte Anmerkungen:

• Die Funktion main ist völlig überflüssig und führt nur dazu, dass der Code weiter eingerückt wird.

• Die Variablen main0 usw. sind gleich mehrfach überflüssig: zum einen, weil sie einfach nur die Werte von $0, $1 und $2 beinhalten, zum anderen, weil man die Werte auch beim Aufruf übergeben könnte und schließlich wegen dem vorherigen Punkt.

• Die Hilfe kannst Du einfacher durch ein Here-Document erzeugen.

• Wenn man Variablen, die nur intern im Skript verwendet und nicht exportiert werden, klein schreibt, ist es ein bisschen übersichtlicher.

• Die Variablen TICK und CROSS werden nur an einer Stelle verwendet, weshalb ich sie komplett streichen würde.

• Die Werte in den Variablen COL_* könnte man ggf. portabler mit tput erzeugen. Damit wäre das Skript noch unabhängiger vom aktuellen Terminal.

rklm schrieb:

Ein paar völlig unsortierte Anmerkungen:

Die natürlich gern gesehen sind. Danke.

• Die Funktion main ist völlig überflüssig und führt nur dazu, dass der Code weiter eingerückt wird.

• Die Variablen main0 usw. sind gleich mehrfach überflüssig: zum einen, weil sie einfach nur die Werte von $0, $1 und $2 beinhalten, zum anderen, weil man die Werte auch beim Aufruf übergeben könnte und schließlich wegen dem vorherigen Punkt.

Im Grunde hast Du Recht. Das Dilemma ist hier eben, ich finde es so übersichtlicher, strukturierter.

• Die Hilfe kannst Du einfacher durch ein Here-Document erzeugen.

Das ist ne Idee

• Wenn man Variablen, die nur intern im Skript verwendet und nicht exportiert werden, klein schreibt, ist es ein bisschen übersichtlicher.

Einer meiner üblichen "Fehler".

• Die Variablen TICK und CROSS werden nur an einer Stelle verwendet, weshalb ich sie komplett streichen würde.

• Die Werte in den Variablen COL_* könnte man ggf. portabler mit tput erzeugen. Damit wäre das Skript noch unabhängiger vom aktuellen Terminal.

Mal reinlesen. tput war mir bisher gar nicht so geläufig.

Auf jeden Fall Danke fürs rein sehen. Im Moment muss das Script sich im harten Alltagseinsatz beweisen. Da wird sicher die ein oder andere Idee noch mit einfließen. Im Moment hab ich jedenfalls viel Spaß, endlich ist das alles mal "aufgeräumt" und zeigt auch die richtigen Fehler an. Und im Gegensatz zu der vorherigen Version, die ich ja hier schon mal dokumentiert habe ( https://forum.ubuntuusers.de/topic/iptables-im-netzwerk-firewall-netzwerkdoku/ ), ist das ein gewaltiger Sprung. ;o)

Wutze schrieb:

rklm schrieb:

Ein paar völlig unsortierte Anmerkungen:

Die natürlich gern gesehen sind. Danke.

Bitte.

• Die Funktion main ist völlig überflüssig und führt nur dazu, dass der Code weiter eingerückt wird.

• Die Variablen main0 usw. sind gleich mehrfach überflüssig: zum einen, weil sie einfach nur die Werte von $0, $1 und $2 beinhalten, zum anderen, weil man die Werte auch beim Aufruf übergeben könnte und schließlich wegen dem vorherigen Punkt.

Im Grunde hast Du Recht. Das Dilemma ist hier eben, ich finde es so übersichtlicher, strukturierter.

😛 Bist Du C-Programmierer? 😉

• Die Variablen TICK und CROSS werden nur an einer Stelle verwendet, weshalb ich sie komplett streichen würde.

• Die Werte in den Variablen COL_* könnte man ggf. portabler mit tput erzeugen. Damit wäre das Skript noch unabhängiger vom aktuellen Terminal.

Mal reinlesen. tput war mir bisher gar nicht so geläufig.

Ich wollte mir auch immer mal^TM diese ganzen Tools und Specs für Terminalbeschreibungen in Ruhe zu Gemüte zu führen. Aber wie das immer so ist...

Auf jeden Fall Danke fürs rein sehen. Im Moment muss das Script sich im harten Alltagseinsatz beweisen. Da wird sicher die ein oder andere Idee noch mit einfließen.

Klar, so etwas ist meistens ein Prozess. Von Zeit zu Zeit kommen dann noch mal neue Anforderungen dazu oder die genannten neuen Ideen. Da bastelt man dann weiter. ☺

Im Moment hab ich jedenfalls viel Spaß, endlich ist das alles mal "aufgeräumt" und zeigt auch die richtigen Fehler an. Und im Gegensatz zu der vorherigen Version, die ich ja hier schon mal dokumentiert habe ( https://forum.ubuntuusers.de/topic/iptables-im-netzwerk-firewall-netzwerkdoku/ ), ist das ein gewaltiger Sprung. ;o)

Prima!