Make vpn-select modular #8
|
@ -0,0 +1,34 @@
|
|||
protocol=fastd
|
||||
|
||||
fastd_clear() {
|
||||
rm /tmp/fastd_fff_peers/*
|
||||
}
|
||||
|
||||
fastd_addpeer() {
|
||||
[ -d /tmp/fastd_fff_peers ] || mkdir /tmp/fastd_fff_peers
|
||||
rohammer marked this conversation as resolved
Outdated
|
||||
|
||||
# write fastd-config
|
||||
json_get_var servername name
|
||||
filename="/etc/fastd/fff/peers/$servername"
|
||||
echo "#name \"${servername}\";" > "$filename"
|
||||
json_get_var key key
|
||||
echo "key \"${key}\";" >> "$filename"
|
||||
json_get_var address address
|
||||
json_get_var port port
|
||||
echo "remote \"${address}\" port ${port};" >> "$filename"
|
||||
echo "" >> "$filename"
|
||||
echo "float yes;" >> "$filename"
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Ich frage mich gerade, ob es klug ist, hier zeilenweise zu schreiben. Da die Dateien aber auf /tmp im RAM liegen, ist es an der Stelle wahrscheinlich wurscht. Keine Ahnung ob die Buffer da Effekte haben... Im Prinzip würde das ja genauso funktionieren? Ich frage mich gerade, ob es klug ist, hier zeilenweise zu schreiben. Da die Dateien aber auf /tmp im RAM liegen, ist es an der Stelle wahrscheinlich wurscht. Keine Ahnung ob die Buffer da Effekte haben...
Im Prinzip würde das ja genauso funktionieren?
` echo "#name \"${servername}\";\nkey \"${key}\";\nremote \"${address}\" port ${port};\n\nfloat yes;" > "$filename"`
adschm
commented
Bitte aber nur als Diskussionsanregung verstehen. Sowas würde ich wenn überhaupt nur in einem separaten Patch anfassen wollen ... Bitte aber nur als Diskussionsanregung verstehen. Sowas würde ich wenn überhaupt nur in einem separaten Patch anfassen wollen ...
jkimmel
commented
Sowas kann man auch mal mit einem here-document loesen. Dann hat man nur ein cat und kann es trotzdem lesen, im Gegensatz zu diesem Einzeiler. Sowas kann man auch mal mit einem here-document loesen. Dann hat man nur ein cat und kann es trotzdem lesen, im Gegensatz zu diesem Einzeiler.
rohammer
commented
Der fastd Kram ist mehr oder weniger eine Kopie von der alten version. Das wollte ich nicht anfassen. Gehoert in einen extra Patch. Der fastd Kram ist mehr oder weniger eine Kopie von der alten version. Das wollte ich nicht anfassen. Gehoert in einen extra Patch.
|
||||
}
|
||||
|
||||
fastd_start_stop() {
|
||||
/etc/init.d/fastd reload # does nothing if fastd was not running
|
||||
|
||||
# fastd start/stop for various situations
|
||||
# this is needed for first start and if fastd comes up or disappears in hoodfile
|
||||
pidfile="/tmp/run/fastd.fff.pid"
|
||||
if [ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ]; then
|
||||
([ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]) || /etc/init.d/fastd start
|
||||
else
|
||||
([ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]) && /etc/init.d/fastd stop
|
||||
fi
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Hmm, subshells. Ob das wieder ich war? Das sollte man auch mal ordentlich machen, aber auch hier separat. Hmm, subshells. Ob das wieder ich war? Das sollte man auch mal ordentlich machen, aber auch hier separat.
adschm
commented
PR #13 PR #13
|
||||
}
|
|
@ -0,0 +1,5 @@
|
|||
uci set fff.vpnselect=fff
|
||||
uci set fff.vpnselect.protocol_order="fastd"
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Eigenlich unterstützen wir noch kein vxlan, insofern würde ich das hier rausnehmen, bis es offiziell unterstützt wird. Eigenlich unterstützen wir noch kein vxlan, insofern würde ich das hier rausnehmen, bis es offiziell unterstützt wird.
rohammer
commented
jo, kann ich raus nehmen. Kommt dann mit dem vxlan Patch wieder rein. jo, kann ich raus nehmen. Kommt dann mit dem vxlan Patch wieder rein.
|
||||
uci commit fff
|
||||
|
||||
exit 0
|
|
@ -1,65 +1,73 @@
|
|||
#!/bin/sh
|
||||
|
||||
# Usage: vpn-select <path-to-hood-file>
|
||||
# To add a new protocol, put a file with three functions to /usr/lib/vpn-select.d/ .
|
||||
# The file must start with protocol=name. It is most important to use the same name here and in hoodfile.
|
||||
# Some parameters of the hood are available via $hood_id, $hood_name and $hood_protocol.
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Typo: available Typo: available
|
||||
# The old config can be cleared in function ${protocol}_clear(). It is called first once per installed protocol.
|
||||
# The function ${protocol}_addpeer() is called for every selected peer in hoodfile.
|
||||
# The function ${protocol}_start_stop() is called at the end once per installed protocol.
|
||||
#
|
||||
# The variable $protocol_order defines the order of preference. The most preffered protocol of the available and offered protocols is selected.
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Typo: "available" Typo: "available"
Hier könnte man auch dann zur Klarstellung darauf hinweisen, dass ein Protokoll hier genannt sein _muss_, damit es funktioniert.
adschm
commented
Typo: preferred Typo: preferred
|
||||
# The $protocol_order is configurable via "uci fff.vpnselect.protocol_order"
|
||||
# An empty protocol_order deactivates VPN.
|
||||
|
||||
|
||||
. /usr/share/libubox/jshn.sh
|
||||
|
||||
hoodfile="$1"
|
||||
|
||||
make_config() {
|
||||
# remove old config
|
||||
rm /tmp/fastd_fff_peers/*
|
||||
# load protocol_order
|
||||
protocol_order="$(uci get fff.vpnselect.protocol_order)"
|
||||
|
||||
# prepare
|
||||
Index=1
|
||||
# source functions
|
||||
for file in /usr/lib/vpn-select.d/*; do
|
||||
[ -f $file ] && . "$file"
|
||||
supported_protocols="$supported_protocols $protocol"
|
||||
done
|
||||
|
||||
adschm
commented
Also zumindest das würde ich mir gerne sparen: Damit haben wir schon mal eine for-Schleife weniger, die bei jedem Run von vpn-select läuft. Als Nebeneffekt können wir dann im Prinzip sogar die ganze supported_protocols Variable entfernen, und einfach am Anfang (clear protocols) und Schluss (apply protocols) jeweils einmal über /usr/lib/vpn-select.d/* iterieren. Das sollte dann auch insgesamt deutlich einfacher zu lesen und verstehen sein. Funktional ändert sich dadurch erstmal nichts, außer dass eben "falsche" Einträge in protocol_order dann Fehler erzeugen, und nicht einfach weggelöscht werden. Also zumindest das würde ich mir gerne sparen:
Erstens würde ich erwarten, das man die Protokolle in protocol_order richtig eintragen kann. Wenn nicht, sollte das nicht silently entfernt werden, sondern dann später im Skript tatsächlich einen Fehler erzeugen, weil die Funktion/Datei nicht gefunden werden kann. So merkt man dann ggf. auch, das man Quatsch eingetragen hat (was in meinen Augen gut ist).
Damit haben wir schon mal eine for-Schleife weniger, die bei jedem Run von vpn-select läuft. Als Nebeneffekt können wir dann im Prinzip sogar die ganze supported_protocols Variable entfernen, und einfach am Anfang (clear protocols) und Schluss (apply protocols) jeweils einmal über /usr/lib/vpn-select.d/* iterieren. Das sollte dann auch insgesamt deutlich einfacher zu lesen und verstehen sein. Funktional ändert sich dadurch erstmal nichts, außer dass eben "falsche" Einträge in protocol_order dann Fehler erzeugen, und nicht einfach weggelöscht werden.
rohammer
commented
Ich versuch das mal genauer zu erklaeren, wie ich zu dieser Variante kam. Wenn man das einfacher hin bekommt waere das klasse. Natuerlich kann man jedes mal die liste der supported_protocols mit ls * holen. Ich mag das gerne einmal in einer Variablen. Aber das ist Geschmacksache. Ich versuch das mal genauer zu erklaeren, wie ich zu dieser Variante kam.
Der Mechanismus mit der protocol_order kam spaeter rein, als mir bewusst wurde, dass ein protokoll, in dem Fall vxlan, protokollspezifische Voraussetzungen pruefen muss. Sind diese nicht erfuellt, ist es noetig, dass es sich aus den moeglichen Protokollen entfernt.
In protocol_order steht also drin, was wir uns wuenschen. Wir wissen nicht, was in der Hood angeboten wird, und ob die technichen Voraussetzungen am Anschluss erfuellt sind. (bei vxlan ist es ipv6) Darum habe ich diese Variable auch als Schalter konzepiert, der durch uci aber auch von den Protokollen bedient werden kann und die Priorisierung wiederspiegelt.
Wenn man das einfacher hin bekommt waere das klasse.
Natuerlich kann man jedes mal die liste der supported_protocols mit ls * holen. Ich mag das gerne einmal in einer Variablen. Aber das ist Geschmacksache.
adschm
commented
Aber welche Protokolle in vpn-select.d liegen wird doch an gleicher Stelle kontrolliert wie der uci Eintrag. Insofern hat der Eintragende ja immer über beides Kontrolle. Entsprechend finde ich das automatische Löschen immer noch unnötig und würde hier einen Fehler erwarten. Aber welche Protokolle in vpn-select.d liegen wird doch an gleicher Stelle kontrolliert wie der uci Eintrag. Insofern hat der Eintragende ja immer über beides Kontrolle. Entsprechend finde ich das automatische Löschen immer noch unnötig und würde hier einen Fehler erwarten.
rohammer
commented
Ich wollte es auch so haben, dass man bei der Firmware einfach fastd oder vxlan raus werfen kann, ohne irgendwas an der Konfiguration aendern zu muessen. Also ist protocol_order durchaus ungleich supported_protocols. Und an der Stelle gleiche ich das ab. Ich wollte es auch so haben, dass man bei der Firmware einfach fastd oder vxlan raus werfen kann, ohne irgendwas an der Konfiguration aendern zu muessen. Also ist protocol_order durchaus ungleich supported_protocols. Und an der Stelle gleiche ich das ab.
Vielleicht kann man das auch ohne den ganzen foo machen. Ich sehe es aber nicht.
adschm
commented
Aber das Löschen ist doch nur dafür da, wenn du zusätzliche Eintrage in protocol_order hast. In der Praxis löscht doch niemand ein Skript aus vpn-select.d und lässt den Eintrag in protocol_order; wenn das so wäre, bräuchten wir protocol_order ja nicht. Insofern muss davon ausgegangen werden, das jeder zusätzliche Eintrag in protocol_order ohne passenden vpn-select.d File einen Fehler darstellt. Aber das Löschen ist doch nur dafür da, wenn du _zusätzliche_ Eintrage in protocol_order hast. In der Praxis löscht doch niemand ein Skript aus vpn-select.d und lässt den Eintrag in protocol_order; wenn das so wäre, bräuchten wir protocol_order ja nicht. Insofern muss davon ausgegangen werden, das jeder zusätzliche Eintrag in protocol_order ohne passenden vpn-select.d File einen Fehler darstellt.
rohammer
commented
Wir haben doch jedes protocol in einem package, das an- oder abgewaehlt werden kann. Wie soll man dann eine Reihenfolge festlegen. Ich muss doch irgendwo sagen, falls fastd da ist, bevorzuge fastd. Und falls es vxlan gibt, setze es an 2. Stelle. Und wenn l2tp vohanden, nimm das vor fastd. usw. Auch wenn man mal die Reihenfolg vom KeyX bezieht, kann man nicht voraussagen, welche protocols auf dem Router vorhanden sind. Meine Loesung gleicht das ab und reagiert auf alle moeglichen Varianten. Ich versuche das vxlan Ding fertig zu machen. Dann sieht man vielleicht noch etwas mehr. Wir haben doch jedes protocol in einem package, das an- oder abgewaehlt werden kann. Wie soll man dann eine Reihenfolge festlegen. Ich muss doch irgendwo sagen, falls fastd da ist, bevorzuge fastd. Und falls es vxlan gibt, setze es an 2. Stelle. Und wenn l2tp vohanden, nimm das vor fastd. usw. Auch wenn man mal die Reihenfolg vom KeyX bezieht, kann man nicht voraussagen, welche protocols auf dem Router vorhanden sind. Meine Loesung gleicht das ab und reagiert auf alle moeglichen Varianten.
Das hab ich auch getestet und funzt.
Und falls das gewuenschte protocol zwar da ist, aber nicht von den Gateways angeboten wird, muss man auch darauf reagieren und das naechste aus der Liste nehmen.
Das ist schon alles ziemlich verzwickt.
Ausserdem muss man auch testen ob ein protocol funktionieren kann, also ob z.B ipv6 da ist. Falls nicht, das naechste aus der Liste nehmen. Das kann aber vpn-select nicht wissen. Das muss das protocol mitbringen. Und ueber das manipulieren der protocol_order habe ich das geloest.
Ich versuche das vxlan Ding fertig zu machen. Dann sieht man vielleicht noch etwas mehr.
|
||||
# compare $protocol_order with $supported_protocols
|
||||
for proto in $protocol_order; do
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Hier würde ggf. auch z.B. "fastd" mit "fastd2" gematcht. Ggf. sollte man word-boundaries in den grep mit einführen. Hier würde ggf. auch z.B. "fastd" mit "fastd2" gematcht. Ggf. sollte man word-boundaries in den grep mit einführen.
jkimmel
commented
eventuell lohnt sich ein blick auf eventuell lohnt sich ein blick auf `man 1 comm` oder aehnliches
|
||||
echo "$supported_protocols" | grep -w $proto >&/dev/null || protocol_order=${protocol_order/$proto/}
|
||||
adschm
commented
Wenn man voraussetzt, das jedes Protokoll in protocol_order eingetragen werden muss, könnte man das etwas vereinfachen:
Wenn man voraussetzt, das jedes Protokoll in protocol_order eingetragen werden muss, könnte man das etwas vereinfachen:
```
# load protocol_order
protocol_order="$(uci get fff.vpnselect.protocol_order)"
# source functions
for p in $protocol_order; do
# only select files that are in protocol_order
file="/usr/lib/vpn-select.d/$p"
[ -f $file ] && . "$file" || continue
# add to supported_protocols if file is found
supported_protocols="$supported_protocols $p"
# clear old config
"${protocol}_clear"
done
```
rohammer
commented
Gefaellt mir gut. Tut genau was ich moechte. Das grep ist weg und es wird ev. nur gesourced, was gebraucht wird. Gefaellt mir gut. Tut genau was ich moechte. Das grep ist weg und es wird ev. nur gesourced, was gebraucht wird.
Vielen Dank!
rohammer
commented
Ach bloed, geht doch nicht. Ich brauche alle supported_protocols zum clear. Sonst können configs uebrig bleiben, wenn man ein protocol aus der Liste protocol_order loescht. Ach bloed, geht doch nicht. Ich brauche alle supported_protocols zum clear. Sonst können configs uebrig bleiben, wenn man ein protocol aus der Liste protocol_order loescht.
adschm
commented
Wie wichtig ist es denn in der Praxis, dass man die Reihenfolge per uci ändern kann? Könnte man nicht einfach die Reihenfolge per prefix vorgeben, wie bei uci-default auch? Also 10-fastd und 20-vxlan? Wir haben ja ohnehin schon zwei Orte (vpn-select.d und hood file), wo wir die Protokolle behandeln müssen. Ich weiß nicht, ob das Ganze besser wird, wenn man jetzt drei hat. Wie wichtig ist es denn in der Praxis, dass man die Reihenfolge per uci ändern kann?
Könnte man nicht einfach die Reihenfolge per prefix vorgeben, wie bei uci-default auch?
Also 10-fastd und 20-vxlan?
Wir haben ja ohnehin schon zwei Orte (vpn-select.d und hood file), wo wir die Protokolle behandeln müssen. Ich weiß nicht, ob das Ganze besser wird, wenn man jetzt drei hat.
adschm
commented
Alternativ könnte man sagen, das man das uci-Setting zum an-/abschalten behält, aber zumindest die Reihenfolge von den Dateien nimmt. Das wäre immer noch deutlich einfacher zu implementieren als mit einer echten protocol order. Alternativ könnte man sagen, das man das uci-Setting zum an-/abschalten behält, aber zumindest die Reihenfolge von den Dateien nimmt. Das wäre immer noch deutlich einfacher zu implementieren als mit einer echten protocol order.
rohammer
commented
Ich hab das ganze umgebaut um den vxlan Client zu machen. Darum habe ich darauf geachtet, dass es voellig unabhaengig voneinander ist. Zum Um/Ein/Ausschalten reicht eine uci Zeile. So kann ich zum testen auch einfach einen tarball auf den Router werfen. Die protocol_order koennte man auch als Hoodparameter vom KeyX beziehen. Wenn man das statischer macht, wird es nur auf den ersten Blick einfacher. Es war echt schick mit diesem Unterbau das vxlan Ding zu bauen. Man muss in keine bestehende Datei rein. Nur die protocol_order. Und die ist konfigurierbar. Ich hab das ganze umgebaut um den vxlan Client zu machen. Darum habe ich darauf geachtet, dass es voellig unabhaengig voneinander ist. Zum Um/Ein/Ausschalten reicht eine uci Zeile. So kann ich zum testen auch einfach einen tarball auf den Router werfen. Die protocol_order koennte man auch als Hoodparameter vom KeyX beziehen. Wenn man das statischer macht, wird es nur auf den ersten Blick einfacher. Es war echt schick mit diesem Unterbau das vxlan Ding zu bauen. Man muss in keine bestehende Datei rein. Nur die protocol_order. Und die ist konfigurierbar.
Ich wuerde es gerne so offen wie moeglich lassen.
adschm
commented
Ich kuck später noch mal, ob man da einen Kompromiss finden kann. Die Entropie ist ja hier recht hoch ... Ich kuck später noch mal, ob man da einen Kompromiss finden kann. Die Entropie ist ja hier recht hoch ...
adschm
commented
Also in jedem Fall kann man die for-Schleife "#clear old config" wegmachen und vorziehen:
Den Rest muss ich mir noch überlegen, mir ist das insgesamt einfach eine Nummer zu kompliziert ... Also in jedem Fall kann man die for-Schleife "#clear old config" wegmachen und vorziehen:
```
# source functions and reset all available protocols
for file in /usr/lib/vpn-select.d/*; do
[ -f $file ] && . "$file" || break
supported_protocols="$supported_protocols $protocol"
"${protocol}_clear"
done
```
Den Rest muss ich mir noch überlegen, mir ist das insgesamt einfach eine Nummer zu kompliziert ...
|
||||
done
|
||||
|
||||
# clear old config
|
||||
for protocol in $supported_protocols; do
|
||||
"${protocol}_clear"
|
||||
done
|
||||
|
||||
# configure vpn
|
||||
|
||||
if [ -n "$hoodfile" ] && [ -s "$hoodfile" ] ; then
|
||||
json_load "$(cat "$hoodfile")"
|
||||
# load hoodparameter
|
||||
json_select hood
|
||||
json_get_var hood_id id
|
||||
json_get_var hood_name name
|
||||
adschm
commented
Benutzen wir die für irgendwas? Benutzen wir die für irgendwas?
rohammer
commented
noch nicht. Die id braucht dann vxlan. noch nicht. Die id braucht dann vxlan.
adschm
commented
Ist zwar kleinkariert, aber würde ich dann auch erst dann einfügen. Macht auch die Änderungen in diesem Patch einfacher nachzuvollziehen. Ist zwar kleinkariert, aber würde ich dann auch erst dann einfügen. Macht auch die Änderungen in diesem Patch einfacher nachzuvollziehen.
rohammer
commented
Die Idee war, eine Basis zu schaffen, auf der jemand ein neues Protokoll hinzufuegen kann, ohne das package vpn-select anfassen zu muessen. Aber wenn es dann besser durchs Karo passt, kommt es weg. Die Idee war, eine Basis zu schaffen, auf der jemand ein neues Protokoll hinzufuegen kann, ohne das package vpn-select anfassen zu muessen. Aber wenn es dann besser durchs Karo passt, kommt es weg.
rohammer
commented
Ich wuerde das gerne lassen, dann muss der vxlan Patch nicht in die vpn-select rein greifen. Ich wuerde das gerne lassen, dann muss der vxlan Patch nicht in die vpn-select rein greifen.
adschm
commented
Aber wenn der vxlan Patch diese Parameter plötzlich nutzt, dann ist doch der vxlan-Patch der Grund, warum die überhaupt da sind. Dann gehören die auch in den vxlan-Patch rein, damit man sie dort findet. D.h. du fasst ja doch im vxlan-Patch vpn-select an, weil du neue Abhängigkeiten erzeugt, du würdest es nur nicht hinschreiben. Aber wenn der vxlan Patch diese Parameter plötzlich nutzt, dann ist doch der vxlan-Patch der Grund, warum die überhaupt da sind. Dann gehören die auch in den vxlan-Patch rein, damit man sie dort findet. D.h. du fasst ja doch im vxlan-Patch vpn-select an, weil du neue Abhängigkeiten erzeugt, du würdest es nur nicht hinschreiben.
adschm
commented
Alternativ könnte man höchstens noch nur diese drei Zeilen in einen Extra-Patch tun, als separate "Vorbereitung" für vxlan. Alternativ könnte man höchstens noch nur diese drei Zeilen in einen Extra-Patch tun, als separate "Vorbereitung" für vxlan.
rohammer
commented
Man koennte auch sagen, die Daten werden angeboten und koennen bei Bedaf genutzt werden. So ne Art Schnittstelle. Die VPNs koennen das nutzen was sie brauchen und sich konfigurieren. Man koennte auch sagen, die Daten werden angeboten und koennen bei Bedaf genutzt werden. So ne Art Schnittstelle. Die VPNs koennen das nutzen was sie brauchen und sich konfigurieren.
|
||||
json_get_var hood_protocol protocol
|
||||
json_select ".."
|
||||
json_select vpn
|
||||
|
||||
# get fastd peers
|
||||
while json_select "$Index" > /dev/null
|
||||
do
|
||||
json_get_keys vpn_keys
|
||||
for k in $vpn_keys; do
|
||||
json_select $k
|
||||
json_get_var protocol protocol
|
||||
if [ "$protocol" = "fastd" ]; then
|
||||
# set up fastd
|
||||
json_get_var servername name
|
||||
filename="/etc/fastd/fff/peers/$servername"
|
||||
echo "#name \"${servername}\";" > "$filename"
|
||||
json_get_var key key
|
||||
echo "key \"${key}\";" >> "$filename"
|
||||
json_get_var address address
|
||||
json_get_var port port
|
||||
echo "remote \"${address}\" port ${port};" >> "$filename"
|
||||
echo "" >> "$filename"
|
||||
echo "float yes;" >> "$filename"
|
||||
fi
|
||||
offered_protocols="$offered_protocols $protocol"
|
||||
json_select ".." # back to vpn
|
||||
Index=$(( Index + 1 ))
|
||||
done
|
||||
json_select ".." # back to root
|
||||
}
|
||||
|
||||
# Only do something if file is there and not empty; otherwise exit 1
|
||||
if [ -s "$hoodfile" ]; then
|
||||
if [ ! -d /tmp/fastd_fff_peers ]; then
|
||||
# first run after reboot
|
||||
mkdir /tmp/fastd_fff_peers
|
||||
make_config
|
||||
# start fastd only if there are some peers
|
||||
[ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ] && /etc/init.d/fastd start
|
||||
else
|
||||
make_config
|
||||
/etc/init.d/fastd reload
|
||||
# select most preferred protocol for this hood
|
||||
adschm
commented
Statt prüfen, Ausgabe unterdrücken, und dann echo könnte man auch einfach den grep direkt das richtige ausgeben lassen (-o). Den Fehler kann man dann auch gleich mit (-q) unterdrücken:
Ansonsten gäbe es noch die klassische Version, hier mal primär als Diskussionsbeitrag:
Statt prüfen, Ausgabe unterdrücken, und dann echo könnte man auch einfach den grep direkt das richtige ausgeben lassen (-o). Den Fehler kann man dann auch gleich mit (-q) unterdrücken:
`selected_protocol=$(for proto in $protocol_order; do echo $offered_protocols | grep -o -q $proto && break; done)`
Ansonsten gäbe es noch die klassische Version, hier mal primär als Diskussionsbeitrag:
```
for proto in $protocol_order; do
echo $offered_protocols | grep -q $proto >/dev/null && {
selected_protocol=$proto
break
}
done
```
rohammer
commented
grep -o -q , sehr schoen. Danke! grep -o -q , sehr schoen. Danke!
rohammer
commented
-o und -q kann man leider nicht kombinieren. -q gewinnt. Es kommt nix raus. -o und -q kann man leider nicht kombinieren. -q gewinnt. Es kommt nix raus.
Ich hab es jetzt nur mit -o gemacht
adschm
commented
Interessant, ich dachte -q wäre für stderr. Offenbar ist es für stdout ... Dann muss man ggf. noch den stderr auch abfangen (bzw. das mal testen). Interessant, ich dachte -q wäre für stderr. Offenbar ist es für stdout ... Dann muss man ggf. noch den stderr auch abfangen (bzw. das mal testen).
rohammer
commented
Ich habe es getestet. stderr muss man nicht abfangen. Ein "no match" ist kein Fehler. Ich habe es getestet. stderr muss man nicht abfangen. Ein "no match" ist kein Fehler.
echo blob | grep foo liefert nie eine Ausgabe auf stderr.
adschm
commented
I see, ich hatte das mit uci -q verwechselt... I see, ich hatte das mit uci -q verwechselt...
rohammer
commented
Auch das -o muss ich wieder zurueck nehmen.
und das matcht natuerlich nicht mit "fastd" Auch das -o muss ich wieder zurueck nehmen.
Bei 2 peers mit z.B. fastd.
```
echo "fastd vxlan fastd" | grep -o fastd
fastd
fastd
```
und das matcht natuerlich nicht mit "fastd"
adschm
commented
geht da -m1? geht da -m1?
adschm
commented
Nö, schade. Aber ich finde sowieso, dass das Ganze irgendwie auch eleganter gehen muss. > geht da -m1?
Nö, schade. Aber ich finde sowieso, dass das Ganze irgendwie auch eleganter gehen muss.
|
||||
selected_protocol=$(for proto in $protocol_order; do echo $offered_protocols | grep -o $proto && break; done)
|
||||
|
||||
# fastd start/stop for various situations
|
||||
pidfile="/tmp/run/fastd.fff.pid"
|
||||
if [ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ]; then
|
||||
([ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]) || /etc/init.d/fastd start
|
||||
else
|
||||
([ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]) && /etc/init.d/fastd stop
|
||||
fi
|
||||
fi
|
||||
exit 0
|
||||
else
|
||||
echo "vpn-select: Hood file not found or empty!"
|
||||
exit 1
|
||||
# configure selected vpns
|
||||
for key in $vpn_keys; do
|
||||
json_select $key
|
||||
json_get_var protocol protocol
|
||||
[ "$protocol" = "$selected_protocol" ] && "${protocol}_addpeer"
|
||||
json_select ".." # back to vpn
|
||||
rohammer marked this conversation as resolved
Outdated
adschm
commented
Der Ordnung halber könnte man hier noch das Der Ordnung halber könnte man hier noch das `json_select ".." # back to root` wieder einfügen, funktional dürfte es egal sein.
rohammer
commented
Kurz danach ist das Skript zu ende. Spielt keine Rolle. Ich lass es so. Kurz danach ist das Skript zu ende. Spielt keine Rolle. Ich lass es so.
|
||||
done
|
||||
fi
|
||||
|
||||
# start/restart/stop vpnservices
|
||||
for protocol in $supported_protocols; do
|
||||
"${protocol}_start_stop"
|
||||
done
|
||||
|
|
|
@ -1,5 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
rm /tmp/fastd_fff_peers/*
|
||||
/etc/init.d/fastd stop
|
||||
|
|
@ -0,0 +1 @@
|
|||
vpn-select
|
||||
adschm
commented
Also persönlich würde ich vpn-stop töten und das in configurehood anpassen. Also persönlich würde ich vpn-stop töten und das in configurehood anpassen.
|
Hmm, gibts es da theoretische Vor- oder Nachteile im Vergleich zu
mkdir -p /tmp/fastd_fff_peers ohne test?
mkdir -p
ist definitiv besser hier.Das fastd fasse ich in diesem Patch nicht an. Braucht einen eigenen.