[Fli4l_dev] Testbericht für das nächste stable Release

[Matthias Taube]

Am 26.10.2014 um 10:40 schrieb Peter Schiefer:

> damit Weihnachten auf Weihnachten fällt, möchten wir Euch aufrufen, den
> aktuellen wöchentlichen testing-Tarball [1] weiteren intensiven Tests zu
> unterziehen und eventuelle Probleme damit hier zu melden, bzw. gleich ein

Hi,
vielen Dank für Eure Entwicklungsarbeit. Fehler habe ich kaum gefunden, 
allerdings möchte ich Euch einen ausführlichen Installationsbericht 
geben, wo es bei mir etwas länger gehakt hat. Vielleicht kann das ja als 
Hinweis dienen, wo die Doku noch etwas ausführlicher sein könnte.

# mkfli4l.txt
Ich nutze ein File _fli4l.txt, welche alle Änderungen gegenüber der 
Standardkonfiguration enthält. Dieses funktioniert für alle Pakete 
wunderbar, nur mkfli4l.sh ignoriert die Einstellungen und greift
ausschließlich auf mkfli4l.txt zu. Es wäre schön, wenn auch für dieses 
File die Einstellungen durch _fli4l.txt überschrieben werden könnten.

# package: base
Es wäre schön, wenn die Variable KERNEL_VERSION automatisch beim 
Entpacken eines Kernel-Pakets gesetzt werden könnte (z.B. indem durch 
die Kernel-Pakete eine Datei kernel.txt im config Verzeichnis gesetzt wird).

Das und wie FLI4L_UUID gesetzt werden muss, war mir nicht klar.

Firewall: Warum geht eigentlich die Verwendung von BIDIRECTIONAL nicht 
mehr zusammen mit Templates? In der Stable geht das noch.

Beim Setzen von Firewall-Regeln kostet es mich immer wieder viel Zeit 
und Versuche, eine iptable-Syntax in einen Fli4l-Konfigurationsbefehl 
umzusetzen. Hier sollten in der Doku viel mehr Beispiele stehen, wie man 
Standardaufgaben (einen Port für ein Netz sperren, einen Port für ein 
Interface sperren, ein Netz für ein Interface sperren) erledigt.

Weiterhin fände ich es schön, wenn man bei der INPUT-Chain erstmal alles 
dicht lassen könnte und bei der Installation eines Paketes (Chrony, 
DHCP, HTTPD) werden dann die entsprechenden Ports auf dem Router als 
Default geöffnet. Ist aber sicher eine Geschmacksfrage.

# package: dns_dhcp
Hier habe ich Hilfe benötigt, wie ipv6-Adressen eingetragen werden. Und 
dann war das nächste (nicht mit dem Fli zusammenhängende) Problem, dass 
diese dann von den Clients im lokalen Netz bevorzugt vor den 
ipv6-Adressen verwendet wurden und ich erstmal alle Dienste im Netz 
ipv6-ready machen musste - so stand ich plötzlich ohne nfs-shares da.

# Package: DYNDNS
Hier habe ich mehrere Stunden damit verbracht, für meinen 
nameserver-hoster (wk-serv.de) eine Konfiguration zu schreiben. 
DYNDNS_DEBUG_PROVIDER ist da keine große Hilfe, da man den trace 
parallel zum Sourcecode durchgehen muss, um mittels Reverse-Engeneering
mühevoll herauszufinden, was eigentlich nicht klappt. Hier wäre es sehr 
schön, wenn man in einer Debug-Einstellung lediglich etwas 
aussagefähigere Fehlermeldungen anstelle eines Trace anfordern könnte 
(Was wurde an den Server gesendet und was kam zurück).

Im Endeffekt waren es folgende Probleme:

Die in Provider.DUMMY gesetzten Variablen
provider_https_sim_error=$ECONN_CONN
provider_https_noauth_sim_error=$EPROV_EMPTY
verhindern ssl, und normalerweise fängt man ja mit dieser Datei als 
Template an

Die Option --sslv3 verhindert heutzutage den Verbindungsaufbau per https.

Mein Provider lässt eine Aktualisierung nur über ipv6 zu, der Tunnel
ist aber zu dem Zeitpunkt des scriptes noch nicht aufgebaut. Mir ist 
nicht klar, ob ich im script einfach ein sleep einbauen kann oder ob das 
unerwünschte Nebeneffekte hat.

Ebenfalls ist es systematisch sehr unschön, dass man im Sourcecode 
(opt/dyndns.txt, check/dyndns.exp) herumpatchen muss. Es wäre besser, 
wenn man das im config-Verzeichnis erledigen könnte.

Nun läuft es aber - falls jemand meine Files braucht bitte melden.

# package: SSHD
Hier wäre eine Info gut, ob man nach den ganzen SSL-Lücken der 
Vergangenheit neue Keys mit SSHD_CREATEHOSTKEYS erstellen muss oder ob 
die alten (mit der Vorversion erstellten) noch sicher sind.

# package: IPV6
Schade, dass man nicht einfach die ipv4-Firewall Einstellungen als 
Default übernehmen kann und nur ipv6-Spezifika neu setzen muss. So 
müssen nun zwei Konfigurationen synchron gehalten werden, was 
fehleranfällig ist.

Auch für die IPv6-Firewall fehlen einfach in der Doku Beispiele, wie man 
Standardaufgaben (z.B. Ping6 aus dem Internet direkt zu den Clients im 
Netz durchlassen) erledigen kann.

# opt/etc/ppp/ip-up900.user
Hier ist ebenfalls das unschöne Patchen im Soucecode erforderlich. Da 
dieses File ausdrücklich dazu dient, nutzerspezifische Anpassungen 
vorzunehmen, sollte eine Konfiguration im config-Verzeichnis möglich sein.

# unix/scripts/parse_cmd.sh
Hier habe ich wieder - wie in allen Vorversionen - remoteremount=true 
gesetzt. Es wäre schön, wenn man das mal in mkfli14l.txt setzen könnte.

+++++++++
Insgesamt ganz herzlichen Dank für Eure Entwicklungsarbeit. Inzwischen 
läuft der Router hier stabil und ich kann mich anderen IPv6-Problemen in 
meinem Netz widmen.


LG
Matthias