[fli4l] Testaufruf für das nächste stable Release

[Christoph Schulz]

Hallo!

Matthias Taube wrote:

> 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.

Vielen Dank für deine Mühe!

> 
> # 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.

Das wird für die 3.10 vermutlich nicht umgesetzt werden, ganz einfach 
deshalb, weil diese Datei einen anderen Charakter hat: Sie wird von mkfli4l 
nicht benutzt, sondern nur von den Skripten, die mkfli4l aufrufen (also 
mkfli4l.sh unter Linux und mkfli4l.bat unter Windows). Die 
Konfigurationsvariablen werden also gar nicht irgendwo anders gesucht. Du 
könntest z.B. auch keine Default-Belegungen in der check/mkfli4l.txt anlegen 
und erwarten, dass diese ausgewertet werden, weil dies etwas ist, was nur 
mkfli4l macht.

> 
> # 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).

Ja, das ist aber so ohne Weiteres eben nicht möglich, ganz einfach aus dem 
Grund, weil man in der Tat mehrere Kernel-Pakete entpacken kann (aber nur 
eins davon dann nutzt). Du kannst also kernel_3_14 und kernel_3_17_virt 
gleichzeitig entpacken und via KERNEL_VERSION dann vor dem Bau zwischen den 
Paketen umschalten. Dein Ansatz würde erfordern, dass man höchstens ein 
Kernel-Paket entpackt.

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

Das steht in der base-Dokumentation, Abschnitt 3.2. Was genau ist unklar? 
Wir verbessern die Dokumentation gerne, vorausgesetzt wir verstehen das 
Problem...

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

Ganz einfach: Weil die Verwendung zu großer Verwirrung führen kann. Um nicht 
alles doppelt aufzuschreiben, verweise ich einfach mal auf FFL-483:

https://ssl.nettworks.org/bugs/browse/FFL-483

> 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.

Die Beispiele in der base-Dokumentation in Abschnitt 3.10.5 sind deiner 
Meinung nach nicht ausreichend? Immerhin sind es ganze acht Seiten...

> 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.

Das wird doch genau so gemacht. OPT_DHCP öffnet z.B. die UDP-Ports 67 und 68 
in der Firewall. Allerdings nur, wenn PF_INPUT_ACCEPT_DEF='yes'. Und ich 
gebe dir Recht, dass dies nicht konsistent durchgezogen ist.

> # package: dns_dhcp
> Hier habe ich Hilfe benötigt, wie ipv6-Adressen eingetragen werden.

Das verstehe ich nicht. Das steht doch in der Dokumentation, nicht?

> 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.

Das ist in der Tat ein Client-Problem, dafür kann der fli4l nichts. Wenn der 
Client IPv6-Adressen anfragt, wird er welche erhalten (wenn der fli4l sie 
liefern kann). Somit muss man auf den Clients IPv6 abschalten, wenn man das 
nicht haben will.

> # Package: DYNDNS
> Hier habe ich mehrere Stunden damit verbracht, für meinen
> nameserver-hoster (wk-serv.de) eine Konfiguration zu schreiben.
> [...]

Dazu kann ich leider nichts sagen, außer dass dyndns für die 4.0 eine Menge 
Veränderungen erfahren hat und noch erfahren wird.

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

Ähm, diese Option wird doch seit dem letzten Tarball gar nicht mehr benutzt 
(siehe FFL-1051) *wunder*.

https://ssl.nettworks.org/bugs/browse/FFL-1051

> 
> Mein Provider lässt eine Aktualisierung nur über ipv6 zu,

Das ist sehr interessant. Unser dyndns-Entwickler hat eher die gegenteilige 
Erfahrung gemacht, dass eine Aktualisierung i.d.R. nur über IPv4 erfolgen 
kann.

> 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.

Das ist leider anders nicht möglich, es sei denn, du bastelst dir ein 
eigenes Paket. Dann kannst du reguläre Ausdrücke in check/dyndns.exp 
erweitern, mit z.B. dem folgenden Schnipsel in einer check/mydyndns.exp:

+DYNDNS_PROVIDER(OPT_MYDYNDNS) = 'MYDYNDNS' : ''

> # 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.

So etwas gehört IMHO ins Wiki, aber nicht in eine Paketdokumentation, da 
solche Dinge schnell veralten.

> 
> # 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.

Das ist für die 4.0 in Planung (bzw. in der Mache), in der 3.10 wird das 
definitiv nichts. Siehe FFL-1066:

https://ssl.nettworks.org/bugs/browse/FFL-1066

> 
> 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.

Mag sein. Wenn du Textbausteine lieferst, baue ich sie ein ;-)

> 
> # 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.

Das verstehe ich nicht. Du kannst eine Datei im Verzeichnis 
config/etc/ppp/ip-up900.user speichern, die dann deinen Code enthält und die 
Version aus dem base-Paket überschreibt. Das geht schon seit vielen Jahren.

> 
> # 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.

Dafür gibt es ja ein Ticket (das ist sogar von dir ;-):

https://ssl.nettworks.org/bugs/browse/FFL-105

> +++++++++
> 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.

Nochmals danke für deinen Erfahrungsbericht!


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]