View Issue Details

IDProjectCategoryView StatusLast Update
0000106Freifunk Franken Firmware[All Projects] Generalpublic2019-10-02 12:49
Reporterrola Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version20180726-beta 
Target Versionnext-stableFixed in Versionnext-stable 
Summary0000106: /etc/hoodfile (hoodfilelocal) funktioniert nicht
DescriptionWenn /etc/hoodfile existiert, gibt es kein /tmp/hoodfile. (s. configurehood Zeile 13 und 72)
Im weiteren Verlauf wird aber auf /tmp/hoodfile ueber /lib/functions/fff/keyxchange referenziert. (z.B. vpn-select Zeile 57) Da geht dann natürlich nichts.
Die Frage ist nun fixen oder hoodfilelocal raus schmeißen.
Man kann damit viel Blödsinn machen, darum bin ich für entfernen.
TagsNo tags attached.

Activities

ChristianD

2018-07-28 20:39

manager   ~0000282

Last edited: 2018-07-28 20:39

View 2 revisions

"Die Frage ist nun fixen oder hoodfilelocal raus schmeißen.
Man kann damit viel Blödsinn machen, darum bin ich für entfernen. "

Wenn wir das rauswerfen, hat man gar keine manuelle Kontrolle mehr über die Hood in die der Router fallen soll (außer halt die Koordinaten aber es kann ja auch Hoods ohne Koordinaten geben die ich manuell betreten will).

Wenn nun Leute an mich herantreten mit 2 Server die "fertig" sind und sich wünschen eine Hood zu testen/anlegen hab ich keine Ahnung wie ich das machen soll ohne sie "scharf" zu schalten und hoffen das mit den Servern alles passt. Gäbe es die hoodfilelocal generiere ich denen eine Hoodfile (bzw. sie können sich auch selbst eine generieren), man spielt sie auf einen Router auf und testet die Server damit ohne das die Hood im KeyXchange steht.

Ich hab das Problem jetzt nicht nachvollzogen bin aber strikt gegen ein rauswerfen.

mfg

Christian

fbl

2018-07-28 21:36

administrator   ~0000283

Das muss schon seit immer kaputt sein.
vpn-select greift schon immer auf Dateien im /tmp zu, dort liegt aber nichts, wenn configurehood dort nichts hin kopiert.

Mein Vorschlag: Statt
hoodfiletmp="$hoodfilelocal" (was nur die Referenz auf die Datei für das aktuelle Skript ersetzt) ein
cp $hoodfilelocal $hoodfiletmp (was sich dann genauso verhält, wie das Laden einer Datei von Ethernet oder Wlan Nachbar).

Vielleicht was noch jemand, warum man das damals anders gemacht hat. Ich kann mir aber keinen Grund vorstellen.

Adrian Schmutzler

2018-07-28 22:58

manager   ~0000284

Ja, das ist schon immer kaputt. Der einzige, der das bisher genutzt hat war Christian, und der hatte sein Gateway in der Hood und keinen VPN gesetzt. (Deshalb hat es nie jemand gemerkt)

Der Grund für die existierende Lösung war schlicht, dass man die Datei nicht nochmal kopieren muss, wenn es sie schon gibt.

Fabians Lösung sollte mE funktionieren und wäre auch nicht unlogisch im Rahmen des restlichen Ablaufes.

Ich hätte aber noch eine andere Idee:
Im Moment rufen wir in vpn-select die Variable hoodfiletmp auf, die in /lib/functions/fff/keyxchange (fff-hoodutils) gesetzt wird.
vpn-select wiederum wird ausschließlich vom configurehood skript aus aufgerufen.

Wäre es nicht viel ordentlicher, wenn man den Namen des hoodfiles (also $hoodfiletmp) als Parameter an vpn-select übergibt?
sh /usr/sbin/vpn-select $hoodfiletmp

Damit würde man die Abhängigkeit der fff-vpn-select von fff-hoodutils komplett los (die auch gar nicht im Makefile steht). Und schließlich soll vpn-select ja den VPN konfigurieren, wo es den hoodfile hernimmt geht die Funktion eigentlich gar nichts an. Ich fände diese Lösung sehr "ordentlich" und würde sie daher aus Code-Stil-Gründen bevorzugen.

Issue History

Date Modified Username Field Change
2018-07-28 20:21 rola New Issue
2018-07-28 20:39 ChristianD Note Added: 0000282
2018-07-28 20:39 ChristianD Note Edited: 0000282 View Revisions
2018-07-28 21:36 fbl Note Added: 0000283
2018-07-28 22:58 Adrian Schmutzler Note Added: 0000284
2018-08-02 11:47 fbl Target Version => next-stable
2018-08-04 07:41 reddog Status new => resolved
2018-08-04 07:41 reddog Resolution open => fixed
2018-08-04 07:41 reddog Fixed in Version => next-stable
2019-10-02 12:48 fbl Category Freifunk Franken Firmware => General
2019-10-02 12:48 fbl Category General => General2
2019-10-02 12:49 fbl Category General2 => General