[RFC 4/4] add package fff-tunneldigger-testing

[Tim Niemeyer]

Hi

Am 5. April 2016 23:54:02 MESZ, schrieb Robert <rlanghammer at web.de>:
>Hallo Tim,
>
>
>Am 05.04.2016 um 22:19 schrieb Tim Niemeyer:
>> Hi
>>
>> Am Dienstag, den 05.04.2016, 14:31 +0200 schrieb Robert Langhammer:
>>> +define Package/fff-tunneldigger-testing
>>> +    SECTION:=base
>>> +    CATEGORY:=Freifunk
>>> +    TITLE:= Freifunk-Franken tunneldigger
>>> +    URL:=http://www.freifunk-franken.de
>>> +    DEPENDS:=+tunneldigger +fff-tunneldigger
>> Hier stimmt was nicht.
>>
>> fff-tunneldigger-testing hängt von tunneldigger und fff-tunneldigger
>ab.
>> Klingt logisch. Aber fff hängt von fff-tunneldigger ab, welches von
>> tunneldigger abhängt.
>> Letztlich wird aber fff-tunneldigger-testing nicht gewählt.
>Genau, da habe ich vorhin schon viel gelernt.
>>
>>> +endef
>>> +
>>> +define Package/fff-tunneldigger-testing/description
>>> +    This is a temporarily package and will be removed 
>>> +    after testing stage.
>> Wenn das nur temporär ist, wo soll die Funktionalität dann später mal
>> hin? Weiter: Warum entfernst du fastd, wenn dieses nur testing ist?
>>
>> Ich würde vorschlagen, dass der Inhalt dieses Packages mit in das
>> fff-tunneldigger kommt. Ich vermute mal, da soll es auch langfristig
>> hin.
>>
>> Dann bauen wir fff-tunneldigger und fff-fastd so, dass sie beide
>> parallel im Image sein können und beide nicht die Vorherschaft
>> übernehmen.
>> Ein neues Package "fff-vpn" hängt dann von fff-tunneldigger und
>> fff-fastd ab. Als Config-Option kann man da drin die default VPN
>Technik
>> wählen. fff-vpn aktiviert dann beim firstboot entweder tunneldigger
>oder
>> fastd und kann idealerweise mit einem kleinen Befehl zwischen den
>VPNs
>> umschalten oder vllt sogar beides gleichzeitig aktivieren?
>>
>> Tim
>Ich denke auch, dass wir da hin kommen sollten. Mir gefällt die Idee,
>das offen und modular zu machen, dann kann jeder der mag seine
>VPN-Lösung einbauen.
>
>Im Moment ist es so, dass nur wenige Gateways einen Broker haben und
>ich
>versucht habe darauf dynamisch zu reagieren. Ich wollte nicht im
>fff-fastd irgend was einbauen, was wir später nicht mehr brauchen und
>diese Art hier den tunneldigger zu konfigurieren werden wir auch nicht
>übernehmen. Das ist absolut keine gute Lösung. Darum dieses package,
>das
>erst mal eine fall-back Lösung ist mit bevorzugtem l2tp.
> 
>Wir haben hier in der Hasberg Hood bis jetzt 5 l2tunnel. Da können wir
>eigentlich noch keine Aussage treffen, ob l2tp überhaupt eine stabile
>Alternative ist, und wir die Sache richtig einbauen sollten.
>Die Idee ist, mit einer Firmware für Interessierte, die man einfach nur
>flasht und wenn l2tp nicht geht fastd macht, noch ein paar Tunnel mehr
>zu bekommen. 
>Dann können wir sehen, was die Gateways machen.
>
>Falls wir uns dafür entscheiden l2tp auf zu nehmen und wir einen Weg
>haben die Broker an die Router zu verteilen (irgend ein keyxchange )
>ist
>das fff-tunneldigger schnell gebaut
>
>Wie müssen die Einrückungen sein? Tabs oder nur einheitlich?

Ich orientiere mich an den Sachen, die schon in der Datei sind.

Sowohl Spaces als auch Tabs haben ihre Vor und Nachteile. Afaik haben wir das aber sogar mal diskutiert und die meisten hatten sich für Spaces ausgesprochen, bis das Argument mit den bash here scripten (cat <<<eof ..) kam.

>Sory wegen dem Wlanslovenia Patch. Mir ist es nicht gelungen den
>einzuspielen, Fehlermeldungen. Da ich mich mit git noch nicht so gut
>auskenne, habe ich einfach deine Anleitung nochmal abgetippt. Dann ging
>es.

Ja, kein Problem. Is ja kein Ding.

Meld dich, wenn du irgendwo mit git nicht klar kommst. Hilfe gibts in der Community immer :)

Tim

>Testen von Vars in "" ist klar. Das kommt von copy and paste ohne
>Hirnaktivität. Danke!
>
>Robert
>
>>
>
>
>
>
>------------------------------------------------------------------------