[Fli4l_dev] Informationen zu den wöchentlichen Archiven vom 17.10.2014 (r34090/r34100)

Christoph Schulz fli4l at kristov.de
Sa Okt 18 09:37:03 CEST 2014 

Hallo,

vorneweg eine Warnung:

#### WICHTIG ####
Im Rahmen von FFL-969 und FFL-997 wurde bemerkt, dass der aktivierte 
cpufreq-Treiber "e_powersaver" als "gefährlich" eingestuft wird. Es ist 
nicht auszuschließen, dass er für dauerhafte Hardware-Schäden verantwortlich 
sein kann. Er wurde im aktuellen Tarball durch "acpi-cpufreq" ersetzt. 
Allen, die einen Rechner vom Typ "winnet-pc680" (IGEL 5/4) nutzen, ist ein 
zügiges Update dringend angeraten!
#### WICHTIG ####

Im Vergleich zu den Archiven vom 10.10.2014 (r33902/r33898) gibt es 
in den Archiven vom 17.10.2014 (r34090/r34100) die folgenden Änderungen:

---------------
Fertiggestellt:
---------------
FFL-700: update des Firmware Pakets
* Die gesamte, von den Kernel-Treibern benötigte Firmware ist jetzt im 
firmware-Paket enthalten (bis auf jene, die nicht enthalten ist ;-), d.h. 
bis auf jene, die nicht auffindbar ist).

FFL-887: ACPI Fehlermeldung auf WRAP (und vermutlich auch ALIX)
* Es wird jetzt davor gewarnt, POWERMANAGEMENT != 'none' auf dem WRAP und 
auf dem ALIX zu benutzen.

FFL-888: Prüfungen auf korrekte Kernel-Architektur bei bekannter Hardware
* Es wird jetzt überprüft, ob die Architektur und die Kernel-Variante zum 
eingestellten HWSUPP-Typ passen.

FFL-1000: hwsupp: generische GPIO-LED Unterstützung
Das LED-System wurde aufgebohrt: Es gibt jetzt einen generischen Treiber für 
alle LEDs, die an GPIO-Anschlüssen hängen. Damit verbunden ist eine neue 
Art, die Verwendung der LEDs im hwsupp-Paket zu konfigurieren. Siehe hierfür 
die Dokumentation.

FFL-1014: hwsupp: Bootfortschritt per LED signalisieren
* Es ist möglich, eine LED während des Boot-Vorgangs dafür zu nutzen, den 
Boot-Fortschritt durch eine spezielle (und konfigurierbare) Boot-Blink-
Sequenz anzuzeigen.

FFL-1015: hwsupp: Unterstützung für I²C Geräte
* Es ist jetzt möglich, via HWSUPP_DRIVER_% weitere Treiber beim Booten zu 
laden und via HWSUPP_I2C_% I²C-Geräte beim Booten zu aktivieren.

FFL-1018: Update auf Kernel 3.14.21
* wurde nie veröffentlicht wg. 3.14.22, s.u.

FFL-1019: Update auf Kernel 3.16.5
* wurde nie veröffentlicht wg. 3.16.6, s.u.

FFL-1021: Falscher Fehlermeldung bei Fehlkonfiguration von 
DNS_AUTHORITATIVE_IPADDR
* Die fehlerhafte Meldung wurde korrigiert.

FFL-1022: Kernel 3.14.22 ist veröffentlicht worden
* Bitte KERNEL_VERSION entsprechend anpassen!

FFL-1023: Kernel 3.16.6 ist da
* Bitte KERNEL_VERSION entsprechend anpassen!

----------
In Arbeit:
----------

FFL-921: Skript für das Erzeugen von Kernel-Paketen erstellen
* Das Skript wurde an die neuen Namen der Kernel-FBR-Pakete angepasst.

FFL-997: hwsupp: cpufreq und Watchdog-support für winnet-pc680
* Für HWSUPP_TYPE="winnet-pc680" (IGEL 5/4) wurde der cpufreq-Treiber 
"e_powersaver" durch den Treiber "acpi-cpufreq" ersetzt, weil ersterer von 
den Kernel-Entwicklern als "gefährlich" eingestuft wird und evtl. für 
Hardware-Schäden verantwortlich sein kann. Bitte dazu auch 
POWERMANAGEMENT='acpi' setzen, weil sonst der Treiber nicht arbeiten kann!

FFL-1020: hwsupp: Inkonsistenzen bei Konfiguration und Abhängigkeiten zu 
anderen Paketen
* Diverse Aufräumarbeiten, insbesondere in Hinblick auf die Trennung der 
hwsupp- und wlan-Pakete.

------------------------------------------------------------
Im FFL-506-Zweig gibt es die folgenden Änderungen (gekürzt):
------------------------------------------------------------

FFL-1003: Weiterentwicklung des Event Subsystems
* r33905: Parameterreihenfolge von mom_unicast umgedreht
* r33906: Laufzeit der Nachrichtenschleife kann nun angegeben werden
* r33909: es kann nun ohne zeitliche Beschränkung auf Nachrichten gewartet 
werden, falls dies nötig sein sollte
* r33919: mom_unicast und mom_broadcast unterstützen nun (wieder) das Warten 
auf Antworten zu einer Nachricht
* r34055: Code robuster gemacht

FFL-875: dyndns Updates
* r34002: weitere Anpassungen an das Circuit-System, insbesondere wird jetzt 
via circuit_is_l3prot_up() geprüft, ob ein Circuit auch online ist, um 
festzustellen, welcher Circuit für ein dyndns-Update verwendet werden soll

FFL-1028: Stil der Meldungen beim Starten und Herunterfahren verbessern
* (diverse): Neuer "Look" für die Meldungen beim Starten und Herunterfahren. 
Kommentare sind erwünscht :-)

FFL-247: imond bedarf einer kompletten Überarbeitung
* r34072, r34075, r34083: Beginn einer Neuentwicklung des Circuit-Dämons. 
Momentan nur verantwortlich für das Anlegen und Löschen von Circuits.

FFL-506: Überarbeitung des Circuit- und Einwähl-Systems
* r33940: Tags wurden durch Circuit-Klassen ersetzt. Die Unterschiede sind 
sowohl syntaktischer als auch semantischer Art: Zu einen erfordern Klassen 
jetzt eine Definition in einem Array (CIRC_CLASS_%). Zum anderen besitzt 
jetzt eine Klasse immer _alle_ Circuits, die zu ihr gehören, unabhängig 
davon, ob der Circuit online ist oder nicht -- Tags waren "dynamisch" und 
wurden erst zugeordnet, wenn der zugehörige Circuit online ging. Aus diesen 
Gründen sollten Circuit-Klassen momentan noch nicht in Firewall-Regeln 
eingesetzt werden, wenn mehr als ein Circuit zu der Klasse gehört, weil der 
Firewall-Code damit (noch) nicht umgehen kann.
* r33948: Circuits können nun in PREROUTING-Regeln verwendet werden, etwa 
so:
    PF_PREROUTING_1='tmpl:http {tunnel-fence} DNAT:@apache'
* r33949: '{...}' in Firewall-Regeln wurde immer als Zielnetz interpretiert, 
auch wenn das Äquivalent IP_NET_x als Quelle eingestuft worden wäre. Dies 
wurde korrigiert.
* r33952: Für DNS_AUTHORITATIVE_IPADDR wurde temporär die Prüfung entfernt, 
ob die angegebene Adresse lokal ist. Dies erlaubt die Nutzung von Circuits 
an dieser Stelle.
* r34018, rc34020: Umbenennung von CIRC_%_ACTIVE zu CIRC_%_UP
* r34019: Einführung von CIRC_%_ENABLED; CIRC_%_ENABLED muss auf 'yes' 
gesetzt werden, damit eine Circuit-Definition auch wirklich genutzt wird. 
Dies ist analog zu OPENVPN_%_ACTIV.
* r34021, r34022: Circuits können in der Konfiguration nur noch über ihren 
Namen referenziert werden, nicht mehr über circ<Nummer> oder <Typ><Nummer>. 
Dies ist, weil die Indizes sich verändern, wenn man Circuits via 
CIRC_%_ENABLED='no' deaktiviert, und somit ist eine Nutzung von Indizes hier 
sehr fehleranfällig geworden.
* r34023: Auch in der IPv6-Konfiguration müssen nun Circuits, die im 
Schnittstellen-Kontext verwendet werden (if:<Circuit>:<Circuit>) in {...} 
geschrieben werden.
* r34024, r34025: Korrektur der Prüfungen, ob ein Circuit auch korrekt 
verwendet wird in Bezug auf das konfigurierte Layer-3-Protokoll (IPv4 vs. 
IPv6); so ist es z.B. unsinnig, in den IPv4-Firewall-Regeln einen Circuit zu 
verwenden, der nur eine IPv6-Konfiguration besitzt.
* r34032. r34033: die benötigten Layer-3-Protokolle für einen Circuit werden 
nun besser detektiert, so dass man weniger häufig explizit 
CIRC_%_PROTOCOLS='...' setzen muss
* r34059, r34060: Verschieben der Einrichtung von PPP-Server-Circuits
* r34064, r34065: Dienste werden beim Herunterfahren mit Hilfe der 
stop_service_message beendet
* r34084: translate_net_if() funktioniert nun auch, wenn der Aufrufer das 
Ergebnis in der Variable "res" gespeichert haben will

------------------

Die "FFL-<Nummer>"-Angaben sind Tickets. Sie können unter
http://bugs.fli4l.de/ eingesehen werden.

------------------
Bekannte Probleme:
------------------

* Im FFL-506-Zweig ist es momentan nicht möglich, Informationen über die 
Domäne und den DNS-Server via DHCPv6 im LAN zu verteilen. Diese 
Funktionalität wird zu einem späteren Zeitpunkt reaktiviert.


Viele Grüße und viel Spaß beim Testen,
-- 
Christoph Schulz
[fli4l-Team]

Mehr Informationen über die Mailingliste Fli4l_dev