DHCP statische IP vergeben?

Wie kann man das Konfigurieren?
BeBiMa
Posts: 2842
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: DHCP statische IP vergeben?

Post by BeBiMa » June 3rd, 2019, 11:06 am

Das ist richtig, aber es gibt einen Patch.
Image
Unitymedia Cable Internet ( 32MBit )

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: DHCP statische IP vergeben?

Post by puls » June 3rd, 2019, 12:49 pm

Auf die Gefahr hin, dass es hier offtopic wird, aber was ist der Grund dafür? Ihr wisst doch, dass das aktuelle Skript nicht funktioniert und ggf sogar Daten löscht. Damit darf das nie wieder an die Benutzer ausgeliefert werden! Ein funktionierendes Skript existiert (ggf auch eins aus einer älteren Version) und kann solange ausgeliefert werden, bis das "neue" Skript fehlerfrei lauffähig ist. Alles andere wäre m.E. unverantwortlich den Benutzern gegenüber. Und das sage ich nicht nur, weil ich vor zwei Wochen in genau diese Falle hineingetappt bin und sie erst spät bemerkt habe. Grundsätzlich muss Software, die schwerwiegende Bugs hat, zurückgehalten und gefixt werden. Sie an Anwender auszuliefern und dann auch noch in einem System, das verfügbare neue Updates grundsätzlich auf allen Seiten der WUI propagiert, ist eine ganz schlechte Idee!

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8522
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: DHCP statische IP vergeben?

Post by Arne.F » June 5th, 2019, 12:32 pm

Auf die Gefahr hin, dass es hier offtopic wird, aber was ist der Grund dafür?
Zeitmangel. Es gibt noch einige Baustellen mehr. (ich sag nur "mds", OpenSSL und IPS)
Inzischen ist der Patch im next und für core133 geplant.

https://git.ipfire.org/?p=ipfire-2.x.gi ... 8bfea0d390
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

BeBiMa
Posts: 2842
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: DHCP statische IP vergeben?

Post by BeBiMa » June 5th, 2019, 12:58 pm

Danke Arne für die Klarstellung.

Unabhängig davon habe ich das gepatchte File wohl oft genug hier im Forum "verteilt", sodass eine direkte Implementierung möglich ist.
Da die Änderung kurz ist ( trotz der Schwere des Fehlers ) und wohl mehrfach getestet wurde, habe ich diesen zusätzlichen "Vetriebsweg" gewählt. Keiner sollte mit der Fehlerkorrektur bis zum nächsten Core-Update warten müssen.
Falls nicht jedem klar war, wohin das File zu speichern ist, tut mir das leid. Eine gezielte Nachfrage hier im Forum bzw. per PN oder Mail wäre hilfreich gewesen. Mich hat in dieser Richtung wenig bis nichts erreicht.

Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

Hellfire
Posts: 697
Joined: November 8th, 2015, 8:54 am

Re: DHCP statische IP vergeben?

Post by Hellfire » June 5th, 2019, 2:40 pm

Solche Problemfälle müsste man an oberster Stelle des Forums (EN und DE) anpinnen, damit die Benutzer gleich sehen was Sache ist. Andererseits ist beim Aufsuchen des Forums das Kind wohl schon in den Brunnen gefallen...

Ich gebe euch schon Recht, dass (auch) andere Themen brennen welche zum nächsten Release fertig sein sollten (müssen), jedoch gibt es einen funktionierenden Patch im Repository, der "nur" mehr gemerged werden müsste und damit auch in Core 132 Einzug halten würde, oder sehe ich das zu einfach?

VG,
Michael
Image

BeBiMa
Posts: 2842
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: DHCP statische IP vergeben?

Post by BeBiMa » June 5th, 2019, 4:00 pm

Der Patch ist gemerged.
Der Zeitpunkt ist durch andere wichtige Topics bestimmt worden. Allerdings war auf jeden Fall vorgesehen, diesen in das nächste Core Update einfliessen zu lassen.
Meine Beiträge hier im Forum sollten nur die Zeit überbrücken. Denn die Funktionalität "Hinzufügen neuer Fixed Leases" war/ist ja definitiv nicht vorhanden.

Zur Historie vielleicht noch eine kleine Anmerkung. Als das Problem bekannt wurde, habe ich es etwas falsch aufgefasst und bin mit einem "dirty fix" vorgeprescht. Dies hat für eine gewisse "Unruhe" in der Entwicklergemeinde geführt, was u.U. zu weiteren Verzögerungen geführt hat. ;)
Allerdings habe ich redlich versucht, dieses Manko zu beseitigen.

Meine persönliche Einschätzung zu diesem Problem und der Lösung:
  • Der Fehler ist schwerwiegend
  • Es wurden "Workarounds" gepostet ( auch im englischen Teil des Forums), die teilweise funktioniert haben und teilweise etwas "abenteuerlich" waren
  • Relativ schnell, nachdem ich das Problem verstanden hatte(;)) habe ich ein gefixtes File gepostet und auch den entsprechenden Patch zur Verfügung gestellt.
  • Eigentlich war recht schnell nach Bekanntwerden des Fehlers eine Lösung vorhanden.
  • Die Korrektur in der Distribution kann nur mittels Core Update erfolgen, dies ist nun mal der festgelegte Ablauf.
  • Bei vorhandener Zwischenlösung gibt es keinen Grund, den Prozess "Core-Update wegen einzelnem Bugfix" anzustossen.
  • Lesen und Nachfragen im Forum hilft ungemein.
Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: DHCP statische IP vergeben?

Post by puls » June 7th, 2019, 8:07 am

Erst einmal danke an Arne und Bernhard für die ausführliche Erläuterung der Umstände. Das ist durchaus ein Pluspunkt für das Projekt, auch wenn das Ergebnis noch immer ein "Geschmäckle" hat.
BeBiMa wrote:
June 5th, 2019, 4:00 pm
Der Patch ist gemerged.
Der Zeitpunkt ist durch andere wichtige Topics bestimmt worden. Allerdings war auf jeden Fall vorgesehen, diesen in das nächste Core Update einfliessen zu lassen.
Meine Beiträge hier im Forum sollten nur die Zeit überbrücken. Denn die Funktionalität "Hinzufügen neuer Fixed Leases" war/ist ja definitiv nicht vorhanden.
Es gibt also seit einiger Zeit einen funktionierenden Patch, der "nur" in das nächste Core Update hineinwandern müsste. Da verstehe ich immer noch nicht, wo die Schwierigkeit liegt. :-\ Das Problem an sich ist effektiv deutlich schwerwiegender als du es dargestellt hast. Es geht ja nicht nur um die Funktionalität "Hinzufügen neuer fixed Leases". Das allein könnte ein Anwender schnell erkennen. Es ist jedoch so, dass vorhandene fixed Leases gelöscht bzw überschrieben werden! Es handelt sich hier also um Datenverlust und nicht lediglich um eine Unbequemlichkeit bei der Konfiguration. Nicht jedem Anwender dürfte sofort auffallen, dass nach dem Hinzufügen eines neuen fixed Lease ein anderer Eintrag aus der Liste verschwunden ist. Wer also mehrere neue Leases anlegt, riskiert, gleich viele vorhandene Leases zu verlieren. In einer Produktivumgebung kann das fatale Auswirkungen haben! Wenn zentrale Systeme nicht mehr über Ihre Stamm-IP erreichbar sind, kann u.U. ein ganzes Netzwerk zusammenbrechen. Die Suche nach der Ursache kann dann Stunden oder gar Tage in Anspruch nehmen mit entsprechendem Ausfall der Produktivität.

Mir ist klar, dass IPfire ein Opensource Projekt ist und der (nicht zahlende) Anwender erst einmal Anspruch auf gar nichts hat. Trotzdem sollten die Entwickler sich ihrer Verantwortung bewusst sein und auch abseits ihrer zahlenden Kunden für ein stabiles System sorgen, insbesondere wenn ein solch schwerwiegender Bug bekannt wird. Mag sein, dass es andere Baustellen gibt, die ebenfalls wichtig sind, doch dürfen dafür nicht die anscheinend kleinen Bugs liegengelassen werden.
Zur Historie vielleicht noch eine kleine Anmerkung. Als das Problem bekannt wurde, habe ich es etwas falsch aufgefasst und bin mit einem "dirty fix" vorgeprescht. Dies hat für eine gewisse "Unruhe" in der Entwicklergemeinde geführt, was u.U. zu weiteren Verzögerungen geführt hat. ;)
Allerdings habe ich redlich versucht, dieses Manko zu beseitigen.
Ein "dirty fix" ist immer noch besser als gar keiner. Zumal angeblich (ich selber habe es nicht getestet sondern dein gepatchtes file benutzt) auch die Version aus einem älteren Core Release fehlerfrei funktionieren sollte. Hier bspw ist mir absolut unverständlich, warum die Entwickler nicht auf diese stabile Version zurückgegriffen haben, um so schnell wie möglich, nämlich gleich mit dem nächsten Core Update, wieder eine funktionierende DHCP-Verwaltung auszurollen. Ein buggy Skript weiterhin in den nächsten Core Updates mit auszuliefern (ja, Plural, denn es sind wohl mindestens drei Core Updates betroffen) ist -- harmlos ausgedrückt -- fahrlässig!
Meine persönliche Einschätzung zu diesem Problem und der Lösung:
  • Der Fehler ist schwerwiegend
  • Es wurden "Workarounds" gepostet ( auch im englischen Teil des Forums), die teilweise funktioniert haben und teilweise etwas "abenteuerlich" waren
  • Relativ schnell, nachdem ich das Problem verstanden hatte(;)) habe ich ein gefixtes File gepostet und auch den entsprechenden Patch zur Verfügung gestellt.
  • Eigentlich war recht schnell nach Bekanntwerden des Fehlers eine Lösung vorhanden.
Das ist prima! So sollte die Entwicklung hinter einem so sicherheitsrelevanten Projekt auch funktionieren! Daher an dieser Stelle nochmal mein persönlicher Dank an dich für die schnelle Bereitstellung eines Fixes! :D
  • Die Korrektur in der Distribution kann nur mittels Core Update erfolgen, dies ist nun mal der festgelegte Ablauf.
  • Bei vorhandener Zwischenlösung gibt es keinen Grund, den Prozess "Core-Update wegen einzelnem Bugfix" anzustossen.
  • Lesen und Nachfragen im Forum hilft ungemein.
Ein festgelegter Ablauf ist prima um ein Standardszenario definieren zu können. Man sollte sich allerdings die Flexibilität offenhalten, in Einzelfällen von einem festgelegten Ablauf abweichen zu können oder diesen zu beschleunigen. Manche nennen das Hotfix oder Securitypatch oder irgendetwas ähnliches. Das ist Usus und sollte insbesondere in einem System, das zentrale Netzwerk- und Sicherheitsaufgaben wahrnehmen soll, als Fallback zur Verfügung stehen. Und auch wenn ich mich wiederhole: Mehrere Core Updates mit fehlerhaftem Skript auszuliefern ist fast schon Vorsatz! Es brauchte ja nicht einmal ein eigenes Coreupdate wegen speziell dieses Fixes. Das funktionierende Skript hätte nur in das nächste, spätestens übernächste Update mit hineingepackt werden müssen. Das zu unterlassen ist ein ganz dicker Negativpunkt für das Projekt! :(

Auch die Annahme, dass die verfügbare Zwischenlösung einen Patch oder eine aktive Information der Anwender überflüssig mache, ist grundsätzlich falsch. Wie Michael bereits bemerkte: "beim Aufsuchen des Forums [ist] das Kind wohl schon in den Brunnen gefallen...". Wer das Forum nicht kennt oder nicht permanent alles mitliest, bekommt also nicht mit, dass ein solcher Bug plus passender Fix existiert, bis es zu spät ist*. Klar, jeder Anwender ist für sein System selbst verantwortlich, muss Backups erstellen und das System im Blick behalten. Aber ganz im Ernst: Wer von euch notiert sich vor dem hinzufügen eines neuen fixed Lease die gesamte Liste und vergleicht diese nach dem Hinzufügen mit der dann aktuellen? Jedesmal! Bei einer handvoll Leases mag der Fehler schnell auffallen, aber wir haben mehrere Dutzend Einträge in der Liste, da fällt es nicht sofort auf, wenn zwei oder drei plötzlich weg sind. Und was ist mit anderen Konfigurationen? Soll ich künftig beim Erstellen eines VPN alle zugehörigen Konfigurationen sichern, vergleichen, irgendwo auf Funktionalität testen um dann irgendwann "produktiv" gehen zu können? Soll ich die Firewallregeln ebenso überprüfen? Nach dem Hinzufügen vielleicht durchzählen, ob die Liste um 1 länger geworden ist und alle anderen Regeln noch so existieren wie vorher? Das wäre absurd und würde den Sinn eines solchen oberflächengesteuerten Systems ad absurdum führen!
* Das Thema Dokumentation ist nochmal ein ganz anderes, darauf will ich hier nicht weiter eingehen. Nur so viel: Es war für mich sehr schwierig überhaupt die richtige Anlaufstelle für solche Fragen zu finden, da weder die Webseite noch das Wiki eine irgendwie hilfreiche Struktur bzw Inhaltsübersicht haben.

Vielleicht könnt ihr ja ein Benachrichtigungssystem einbauen, über das die Anwender über kritische Fehler oder Security Bugs informiert werden. Da IPfire standardmäßig täglich nach Updates sucht, wäre es eine Kleinigkeit, an dieser Stelle Informationen an die Anwender auszurollen. Es würde reichen, in der WUI eine kurze, farbig markierte Benachrichtigungszeile einzublenden, die mit kurzem Stichwort zu einer entsprechenden Wiki- oder Forumsseite verlinkt.

So, jetzt bin ich das mal losgeworden. Es fühlt sich hoffentlich niemand auf den Schlips getreten (zumindest nicht ungerechtfertigt) und falls der Ton vielleicht etwas aggressiv wirkt, dann nur deshalb, weil ich das Thema (Daten-)Sicherheit sehr ernst nehme und auf Schludrigkeit recht humorlos reagiere. Trotz allem möchte ich den Entwicklern und insbesondere den freiwilligen Helfern meinen Dank und auch meinen Respekt ausdrücken, dass ihr euch seit oftmals vielen Jahren diesem Projekt widmet und es kontinuierlich vorwärts bringt. Ich wünsche euch weiterhin viel Kraft und hoffe, dass ihr euch auch durch Meckerfritzen wie mich nicht demotivieren lasst!

Euch allen wünsche ich ein schönes, sommerliches Pfingstwochenende! 8)

DJ-Melo
Posts: 678
Joined: July 8th, 2014, 7:12 am

Re: DHCP statische IP vergeben?

Post by DJ-Melo » June 7th, 2019, 9:04 am

Hallo,

ich nutze Ipfire nicht als DHCP "umschiffe" das Problem also, dennoch schließe ich mich meinem Vorredner an, der DHCP bereich ist ja betriebsrelevant daher hatte ich auch extra nochmal nachgefragt, weil im Forum ja manches gern schnell untergeht. Evtl hätte man es einfach in die top ten aufnehmen oder mal nen Blogeintrag dazu verfassen können/dürfen. Einfach damit die Information schneller zur Verfügung steht.

Trotzdem Danke für Arbeit!

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8522
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: DHCP statische IP vergeben?

Post by Arne.F » June 7th, 2019, 9:14 am

Ein buggy Skript weiterhin in den nächsten Core Updates mit auszuliefern (ja, Plural, denn es sind wohl mindestens drei Core Updates betroffen) ist -- harmlos ausgedrückt -- fahrlässig!
Eigentlich sollte eine Änderung in core131 den Bug Fixen. Leider war in der Version ein weitere Bug in diesem Fix der nicht während der Testphase gefunden wurde. (Hat das keiner Getestet?)
Und da wir normal direkt nach release eines Core updates das nächste für das Testing bauen hat man halt das Problem das es erst ins nächste core kommt.

Heute releasen wir core132 und bauen core133 übers Wochenende zum Test. Wenn also in core132 jetzt ein Bug drin der in der Testphase nicht gefunden wurde und wir core133 nicht nochmal neu bauen kommt der Fix erst in core134.
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

DJ-Melo
Posts: 678
Joined: July 8th, 2014, 7:12 am

Re: DHCP statische IP vergeben?

Post by DJ-Melo » June 7th, 2019, 9:28 am

Hallo,

Danke für die Erläuterungen könnte man das Thema nicht trotzdem pinnen? Einfach damit Betroffene das schneller finden.

Gruß

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: DHCP statische IP vergeben?

Post by puls » June 7th, 2019, 9:50 am

Hallo Arne,
danke für die kurzfristige Antwort!
Arne.F wrote:
June 7th, 2019, 9:14 am
Ein buggy Skript weiterhin in den nächsten Core Updates mit auszuliefern (ja, Plural, denn es sind wohl mindestens drei Core Updates betroffen) ist -- harmlos ausgedrückt -- fahrlässig!
Eigentlich sollte eine Änderung in core131 den Bug Fixen. Leider war in der Version ein weitere Bug in diesem Fix der nicht während der Testphase gefunden wurde. (Hat das keiner Getestet?)
Nicht zu testen wäre natürlich sehr uncool! So etwas sollte nicht passieren. Da ich eure interne Struktur nicht kenne und auch nicht weiss, wie viele Leute mit Entwicklung und QM beschäftigt sind, kann ich nicht beurteilen, wie hoch der Veröffentlichungsdruck auf einzelnen Entwicklern ist. Mir ist absolut bewusst, dass das Testen von Fixes und speziell auch von neuen oder überarbeiteten Funktionen sehr zeitaufwändig sein kann. Aber Basistests sollten doch in jedem Fall stattfinden. In diesem Fall hätte das Anlegen und modifizieren der Leasestabelle sofort gezeigt, dass der Fix nicht wie gewünscht funktioniert.
Und da wir normal direkt nach release eines Core updates das nächste für das Testing bauen hat man halt das Problem das es erst ins nächste core kommt.
Heute releasen wir core132 und bauen core133 übers Wochenende zum Test. Wenn also in core132 jetzt ein Bug drin der in der Testphase nicht gefunden wurde und wir core133 nicht nochmal neu bauen kommt der Fix erst in core134.
Genau da sehe ich allerdings ein Problem: Wenn ein Bug in 132 gefunden wird, der für 133 behoben werden könnte, warum sollte 133 dann nicht neu gebaut werden um den Fix zu enthalten? Zwischen den Releases vergehen ja durchaus mal mehrere Wochen. Sollen Probleme dann lieber für diese Dauer bestehen bleiben als ggf das Release noch einmal neu zu bauen und es eventuell mit einem Tag Verzögerung zu veröffentlichen?

Um einmal die Dauer zu verdeutlichen: Das erste Posting zu diesem Fehler stammt vom 20. April. Heute ist der 7. Juni und eventuell erscheint heute ein Release mit einer funktionierenden dhcp.cgi. Dazwischen liegen sieben Wochen. Eine sehr lange Zeit dafür, dass nur eine Vorgängerversion eines Skripts hätte verteilt werden müssen. Ich habe Verständnis, dass Ihr die Skripte gerne mal umbauen und vielleicht modernisieren wollt, aber dann im Hauruckverfahren ein verbuggtes Skript nach dem anderen Auszuliefern um nur nicht auf die ältere Version zurückgreifen zu müssen, ist kontraproduktiv. Warum wurde nicht als allererstes wieder die Version aus Core128 eingebaut, um das neue Skript dann in Ruhe überarbeiten und testen zu können? Das hätte allen Beteiligten eine Menge Zeit und Ärger erspart.

BeBiMa
Posts: 2842
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: DHCP statische IP vergeben?

Post by BeBiMa » June 7th, 2019, 10:03 am

puls wrote:
June 7th, 2019, 8:07 am
Es gibt also seit einiger Zeit einen funktionierenden Patch, der "nur" in das nächste Core Update hineinwandern müsste. Da verstehe ich immer noch nicht, wo die Schwierigkeit liegt. :-\ Das Problem an sich ist effektiv deutlich schwerwiegender als du es dargestellt hast. Es geht ja nicht nur um die Funktionalität "Hinzufügen neuer fixed Leases". Das allein könnte ein Anwender schnell erkennen. Es ist jedoch so, dass vorhandene fixed Leases gelöscht bzw überschrieben werden! Es handelt sich hier also um Datenverlust und nicht lediglich um eine Unbequemlichkeit bei der Konfiguration.
Du beschreibst den Fehler recht exakt. Die Symptome sind auch mehrfach in verschiedenen Threads beschrieben. Einigen wir uns darauf, dass meine Fehlerkorrektur die Ursache und damit auch die Symptome beseitigt.
puls wrote:
June 7th, 2019, 8:07 am
Mir ist klar, dass IPfire ein Opensource Projekt ist und der (nicht zahlende) Anwender erst einmal Anspruch auf gar nichts hat. Trotzdem sollten die Entwickler sich ihrer Verantwortung bewusst sein und auch abseits ihrer zahlenden Kunden für ein stabiles System sorgen, insbesondere wenn ein solch schwerwiegender Bug bekannt wird. Mag sein, dass es andere Baustellen gibt, die ebenfalls wichtig sind, doch dürfen dafür nicht die anscheinend kleinen Bugs liegengelassen werden.
Es gibt durchaus Entwickler, die keinerlei finanzielle Interessen im IPFire-Projekt haben. Dazu zähle auch ich. Ich beobachte sehr intensiv das Forum und lese ( und schreibe ) in der Devel-Mailliste. Probleme, die ich mit meinem System reproduzieren kann, versuche ich zu lösen. Das Einfliessenlassen in die Distri überlasse ich denjenigen, die dafür zuständig sind. Opensource bedeutet ja nicht, dass jeder auch Änderungen durchführen darf. Und das ist gut so.
puls wrote:
June 7th, 2019, 8:07 am
Zur Historie vielleicht noch eine kleine Anmerkung. Als das Problem bekannt wurde, habe ich es etwas falsch aufgefasst und bin mit einem "dirty fix" vorgeprescht. Dies hat für eine gewisse "Unruhe" in der Entwicklergemeinde geführt, was u.U. zu weiteren Verzögerungen geführt hat. ;)
Allerdings habe ich redlich versucht, dieses Manko zu beseitigen.
Ein "dirty fix" ist immer noch besser als gar keiner.
Kommt auf die Definition von "dirty" an. In diesem Falle war es wie in den meisten Fällen: eine Lösung, die in einem speziellen Fall scheinbar funktionert hat, ohne den Grund zu kennen. Diese Fixes sind abzulehnen, was auch geschah.
puls wrote:
June 7th, 2019, 8:07 am
Ein buggy Skript weiterhin in den nächsten Core Updates mit auszuliefern (ja, Plural, denn es sind wohl mindestens drei Core Updates betroffen) ist -- harmlos ausgedrückt -- fahrlässig!
Mir ist eigentlich nur der aktuelle CoreUpdate 131 als buggy bekannt. Vorher habe ich weder im Forum, noch im Bugzilla entsprechende Meldungen gesehen.
puls wrote:
June 7th, 2019, 8:07 am
Ein festgelegter Ablauf ist prima um ein Standardszenario definieren zu können. Man sollte sich allerdings die Flexibilität offenhalten, in Einzelfällen von einem festgelegten Ablauf abweichen zu können oder diesen zu beschleunigen. Manche nennen das Hotfix oder Securitypatch oder irgendetwas ähnliches. Das ist Usus und sollte insbesondere in einem System, das zentrale Netzwerk- und Sicherheitsaufgaben wahrnehmen soll, als Fallback zur Verfügung stehen.
Den Hotfix gab es recht schnell in Form des von mir bereit gestellten Files.
puls wrote:
June 7th, 2019, 8:07 am
Und auch wenn ich mich wiederhole: Mehrere Core Updates mit fehlerhaftem Skript auszuliefern ist fast schon Vorsatz! Es brauchte ja nicht einmal ein eigenes Coreupdate wegen speziell dieses Fixes. Das funktionierende Skript hätte nur in das nächste, spätestens übernächste Update mit hineingepackt werden müssen. Das zu unterlassen ist ein ganz dicker Negativpunkt für das Projekt! :(
Noch einmal, wieso mehrer CoreUpdates? Der Patch ( das sind die Änderungen für den Übergang vom defekten zum funktionierenden File ) wurde dem nächsten Update zugefügt. Schneller geht es wohl nicht.
puls wrote:
June 7th, 2019, 8:07 am
Vielleicht könnt ihr ja ein Benachrichtigungssystem einbauen, über das die Anwender über kritische Fehler oder Security Bugs informiert werden. Da IPfire standardmäßig täglich nach Updates sucht, wäre es eine Kleinigkeit, an dieser Stelle Informationen an die Anwender auszurollen. Es würde reichen, in der WUI eine kurze, farbig markierte Benachrichtigungszeile einzublenden, die mit kurzem Stichwort zu einer entsprechenden Wiki- oder Forumsseite verlinkt.
An sich keine schlechte Idee. Entwickle ein Konzept zur Realisierung und stelle dieses in der Entwicklungs-Mail-Liste vor.
puls wrote:
June 7th, 2019, 8:07 am
Ich wünsche euch weiterhin viel Kraft und hoffe, dass ihr euch auch durch Meckerfritzen wie mich nicht demotivieren lasst!
Meckerfritzen gibt es auch unter den Entwicklern. Bisher haben sich deswegen weder die CoreDevelopper noch die betreffenden "Fritze" entmutigen lassen. :)

Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

BeBiMa
Posts: 2842
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: DHCP statische IP vergeben?

Post by BeBiMa » June 7th, 2019, 10:44 am

Ohne noch mal die ganze Historie in Forum, Mailliste und Bugzilla nachgelesen zu haben, eine kurze Zusammenfassung aus meiner persönlichen Sicht:
  • Mehrfach wird angemerkt, dass es "unbequem" ist, wenn jedes Zufügen einer festen-IP-Definition extra bestätigt werden muss, damit sie wirksam wird
  • Dies versuchte eine Änderung im .cgi-File zu ändern. Diese Änderung erzeugte einen wirklichen Fehler.
  • Dieser Fehler wurde in einem etwas längeren Prozess ( wegen Missverständnissen ) behoben.
  • Die Fehlerkorrektur wurde von mir in der dafür vorgesehenen Mailliste publiziert. Zusätzlich habe ich wegen der Schwere des Fehlers die korrigierte Datei hier im Forum zur Verfügung gestellt.
  • Zum nächstmöglichen Zeitpunkt ( CoreUpdate 132 ) ist das korrigierte File Teil der Distribution.
  • Ein intensiver Test bzw. ( besser ) die Verifikation des Patches hätte den Prozess abkürzen und entschärfen können. Dies ist nicht geschehen und damit Geschichte, leider.
Für die Zukunft bleiben eigentlich nur zwei Erkenntnisse:
- Jeder, der die Möglichkeit hat, sollte die Testversion testen und Auffälligkeiten melden.
- Jeder, der die Möglichkeit und Fähigkeit hat, sollte die Änderungen im Sourcepool zumindest von Zeit zu Zeit prüfen. Evtl. Unstimmigkeiten können im Forum oder besser in der Mailliste gepostet werden.
Denn nur so kann ein Opensource-Projekt wie IPFire gut funktionieren. Wir sind keine kommerzielle Organisation, die ein Produkt aus Opensource-Quellen "zusammenzimmert", sondern eine Gemeinschaft von Entwicklern und Anwendern einer unabhängigen Firewall. Dies ändert sich auch nicht durch die Tatsache, dass einige Mitglieder ihre Brötchen durch HW-Verkauf und professionellen Support für IPFire verdienen.

BTW: Für mich ist das Thema DHCP-Konfiguration noch nicht ganz erledigt. Ich versuche das File "kosmetisch" durch Kommentare verständlicher und damit wartbarer zu machen. Ausserdem soll die Bedienung u.U. intuitiver werden.
D.h. ich bin für Vorschläge in dieser Richtung empfänglich. Auch was eventuelle zusätzliche Möglichkeiten der Konfiguation des dhcpd angeht.


Bernhard
Image
Unitymedia Cable Internet ( 32MBit )

puls
Posts: 25
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: DHCP statische IP vergeben?

Post by puls » June 7th, 2019, 11:21 am

BeBiMa wrote:
June 7th, 2019, 10:03 am
puls wrote:
June 7th, 2019, 8:07 am
Mir ist klar, dass IPfire ein Opensource Projekt ist und der (nicht zahlende) Anwender erst einmal Anspruch auf gar nichts hat. Trotzdem sollten die Entwickler sich ihrer Verantwortung bewusst sein und auch abseits ihrer zahlenden Kunden für ein stabiles System sorgen, insbesondere wenn ein solch schwerwiegender Bug bekannt wird. Mag sein, dass es andere Baustellen gibt, die ebenfalls wichtig sind, doch dürfen dafür nicht die anscheinend kleinen Bugs liegengelassen werden.
Es gibt durchaus Entwickler, die keinerlei finanzielle Interessen im IPFire-Projekt haben. Dazu zähle auch ich. Ich beobachte sehr intensiv das Forum und lese ( und schreibe ) in der Devel-Mailliste. Probleme, die ich mit meinem System reproduzieren kann, versuche ich zu lösen. Das Einfliessenlassen in die Distri überlasse ich denjenigen, die dafür zuständig sind. Opensource bedeutet ja nicht, dass jeder auch Änderungen durchführen darf. Und das ist gut so.
Völlig richtig, das verschnüren auslieferungsfertiger Pakete sollten einigen wenigen Leuten vorbehalten bleiben, die dann aber nach einem gewissen Standard vorgehen sollten. U.a. sollte sichergestellt sein, dass jede Änderung die in ein Release fliesst, vorher getestet wurde. Und genau diesen Entwicklern wäre es auch möglich gewesen, eine vorherige Version "wiederherzustellen", solange für die gefixte Version nicht alle Tests sauber abgeschlossen sind. So wie es gelaufen ist, hat es leider etwas von Bananaware.
puls wrote:
June 7th, 2019, 8:07 am
Zur Historie vielleicht noch eine kleine Anmerkung. Als das Problem bekannt wurde, habe ich es etwas falsch aufgefasst und bin mit einem "dirty fix" vorgeprescht. Dies hat für eine gewisse "Unruhe" in der Entwicklergemeinde geführt, was u.U. zu weiteren Verzögerungen geführt hat. ;)
Allerdings habe ich redlich versucht, dieses Manko zu beseitigen.
Ein "dirty fix" ist immer noch besser als gar keiner.
Kommt auf die Definition von "dirty" an. In diesem Falle war es wie in den meisten Fällen: eine Lösung, die in einem speziellen Fall scheinbar funktionert hat, ohne den Grund zu kennen. Diese Fixes sind abzulehnen, was auch geschah.
Das habe ich wohl missverständlich formuliert: Der "Dirty Fix" sollte keineswegs in ein Release eingebaut werden. So etwas ist aber als schnelle Abhilfe für betroffene Anwender wichtig, um die Zeit bis zum richtigen Bugfix mit dem nächsten Release zu überbrücken. In diesem Sinne: Besser dirty gefixt als gar nicht.
puls wrote:
June 7th, 2019, 8:07 am
Ein buggy Skript weiterhin in den nächsten Core Updates mit auszuliefern (ja, Plural, denn es sind wohl mindestens drei Core Updates betroffen) ist -- harmlos ausgedrückt -- fahrlässig!
Mir ist eigentlich nur der aktuelle CoreUpdate 131 als buggy bekannt. Vorher habe ich weder im Forum, noch im Bugzilla entsprechende Meldungen gesehen.
Da muss ich dich korrigieren: Im sechsten Beitrag in diesem Stang, von Dietmar am 23.4. verfasst, heisst es:
sammydk wrote:
April 23rd, 2019, 10:52 am
mit Update auf 130 ist das Problem immer noch vorhanden, ein Eintragen von weitern statischen Einträgen ist nicht möglich.
Vorher wird von Matthias die funktionierende Version aus Core128 empfohlen. Dem entnehme ich, dass das Problem mit Core129 eingeführt wurde und seither auf einen endgültigen Fix wartet. Wir haben also 129, 130 und 131 als betroffene Versionen.
puls wrote:
June 7th, 2019, 8:07 am
Ein festgelegter Ablauf ist prima um ein Standardszenario definieren zu können. Man sollte sich allerdings die Flexibilität offenhalten, in Einzelfällen von einem festgelegten Ablauf abweichen zu können oder diesen zu beschleunigen. Manche nennen das Hotfix oder Securitypatch oder irgendetwas ähnliches. Das ist Usus und sollte insbesondere in einem System, das zentrale Netzwerk- und Sicherheitsaufgaben wahrnehmen soll, als Fallback zur Verfügung stehen.
Den Hotfix gab es recht schnell in Form des von mir bereit gestellten Files.
Das ist richtig, auch wenn er für einen nicht im Forum beheimateten Anwender schwer zu finden war.
puls wrote:
June 7th, 2019, 8:07 am
Und auch wenn ich mich wiederhole: Mehrere Core Updates mit fehlerhaftem Skript auszuliefern ist fast schon Vorsatz! Es brauchte ja nicht einmal ein eigenes Coreupdate wegen speziell dieses Fixes. Das funktionierende Skript hätte nur in das nächste, spätestens übernächste Update mit hineingepackt werden müssen. Das zu unterlassen ist ein ganz dicker Negativpunkt für das Projekt! :(
Noch einmal, wieso mehrer CoreUpdates? Der Patch ( das sind die Änderungen für den Übergang vom defekten zum funktionierenden File ) wurde dem nächsten Update zugefügt. Schneller geht es wohl nicht.
Siehe oben. Falls ich mit der zeitlichen Einordnung des Bugs doch falsch liege, bin ich für Aufklärung dankbar! Vielleicht reden wir hier über zwei unterschiedliche Bugs die im selben Kontext auftreten?
puls wrote:
June 7th, 2019, 8:07 am
Vielleicht könnt ihr ja ein Benachrichtigungssystem einbauen, über das die Anwender über kritische Fehler oder Security Bugs informiert werden. Da IPfire standardmäßig täglich nach Updates sucht, wäre es eine Kleinigkeit, an dieser Stelle Informationen an die Anwender auszurollen. Es würde reichen, in der WUI eine kurze, farbig markierte Benachrichtigungszeile einzublenden, die mit kurzem Stichwort zu einer entsprechenden Wiki- oder Forumsseite verlinkt.
An sich keine schlechte Idee. Entwickle ein Konzept zur Realisierung und stelle dieses in der Entwicklungs-Mail-Liste vor.
Ich fürchte, ich müsste mich dafür erst einmal in die Strukturen von IPfire einarbeiten, wofür ich definitiv keine Zeit habe, Falls ein eher abstraktes Modell reicht, kann ich dieses gerne erstellen. Ich gehe aber davon aus, dass die Infrastruktur im Prinzip bereits vorhanden ist. Denn für Core-Updates gibt es ja bereits ein Benachrichtigungsmodell. Genau so könnte auch die Abfrage nach kritischen Bugs funktionieren.
puls wrote:
June 7th, 2019, 8:07 am
Ich wünsche euch weiterhin viel Kraft und hoffe, dass ihr euch auch durch Meckerfritzen wie mich nicht demotivieren lasst!
Meckerfritzen gibt es auch unter den Entwicklern. Bisher haben sich deswegen weder die CoreDevelopper noch die betreffenden "Fritze" entmutigen lassen. :)
Das finde ich so faszinierend an OS Projekten: Man hört viel von Reibereien, Streits oder gar offenen Anfeindungen unter den Entwicklern und nicht wenige Projekte haben die häufigsten Rückmeldungen von übersättigten Anwendern, die mit einer absurden Anspruchshaltung freie Software nutzen und bei Fehlern mit harten Worten die Entwickler beschimpfen und auf imaginäre Rechte pochen und trotzdem bleiben die Leute am Ball und machen weiter. Ich ziehe den Hut vor diesen Menschen!

BeBiMa
Posts: 2842
Joined: July 30th, 2011, 12:55 pm
Location: Mannheim

Re: DHCP statische IP vergeben?

Post by BeBiMa » June 7th, 2019, 12:11 pm

Bezüglich der Abläufe habe ich mich gerade mal im Bugzilla schlau gemacht.
Du hast recht, offensichtlich wurde der Fehler mit Update 129 eingebracht.
Allerdings sind es tatsächlich zwei Probleme:
- das Hinzufügen eines neuen fixed lease benötigt(e) zwei Schritte: Eintragen der Daten,"hinzufügen","ändern". Dies führte zu einem Verlust der Definition bei einem Wechsel der Seite vor dem zweiten Schritt.
- die Korrektur dieser Unzulänglichkeit hat den zweiten sehr schwerwiegenden Fehler erzeugt. Eine Neudefinition löschte alte Definitionen.

Die Diskussion im Bugzilla bzw. im englischen Forum drehte sich mehr um den ersten Fehler. Warum der zweite Fehler nicht im Testing-Tree aufgefallen ist, ist mir allerdings schleierhaft. Kann nur wiederholen, möglichst jeder ( vor allem "Nur-Benutzer" ) sollte die Testversion prüfen.

Die Anzahl der betroffenen Core-Update-Versionen erklärt sich übrigens ganz einfach dadurch, dass in dieser Zeit einge wirklich dringende Sicherheitsupdates durchgeführt werden mussten. Da dies oft auch den Kernel betrifft, geht das nur über vorgezogene Updates. Die "normale laufende" Arbeit bleibt dabei aussen vor.
Image
Unitymedia Cable Internet ( 32MBit )

Post Reply