Post by Heinz-Peter FaasenPost by Marcus RöckrathPost by Ulrich HupeKönnte man den dann nicht, wie jedes andere Linuxsystem, über Putty etc
ein update/upgrade machen?
Ein Router ist nicht "wie jedes andere" Linuxsystem. Er sollte "sicher
by Design" sein (=Aktuelle Basis), WAN-Seitig keine Serverdienste/Ports
offen lassen und den rest mit einem paketfilter zu nageln können.
Ein Grund für EISFAIR war ja das es immer mehr Serverdienste für den FLI
gab - was nicht seine Aufgabe ist.
Post by Heinz-Peter FaasenPost by Marcus RöckrathUm Updates auf irgendeinem "Weg" durchzuführen, müssen sie doch erstmal zu
Verfügung stehen. Du kannst nicht einfach Binaries einer anderen
Distribution auf einen fli4l übertragen.
Hab lange nicht nach/rein geschaut. Wenn die kernelkonfig datei beiliegt
könnte man "prinzipiell" einen upstream-kernel der gleichen version
besorgen und mit der konfig kompilieren.... und dann muß man noch
Sicherheitsrelevante Patches finden und ebenso (alle, auswahl) vorher
einbinden. Wenn der kernel dann nicht baut hat man mit zitronen
gehandelt und muß suchen ob sich da was beißt. Wo fängt man da an, wo
hört diese Arbeit dann auf?
Alternative: gleiche Version, Einen Backports-Kernel suchen der schon
alle patches drin hat - wenn's den gibt. Und fortan der neuen Version
hinterher hecheln. Und nötige Änderungen am paketfilter und
userland-programmen auch noch im Auge behalten.
Ich WEISS NICHT wie viel Arbeit das macht - aber es ist bestimmt NICHT
wenig. Nix was man mal so in 5 min. durch sieht und dann nur noch drauf
wartet das der compiler ein binary ausspuckt. Das man zumindest auch mal
testweise starten sollte bevor man es eintütet oder?
Post by Heinz-Peter Faasenund mit Putty hat das Ganze schon gar nichts zu tun, denn man baut beim
fli ja erst mal ein Image auf einem anderen Rechner. ;)
Der Kernel ist m.W. schon als fertiges image (2 oder 3 Varianten)
vorhanden. Was da "gebaut" wird ist eher eine initrd und die opt.tgz für
das was der router im betrieb braucht. Und das wird m.W. nur durch 'tar'
und 'gz' geschoben. Also sachen wie init, pppd, ipchains, ls...
hdinstall... Was ein "normales" Linux einfach per paketmanager
tüddelfertig auf die Platte wirft.
BTW. Ich kenne von früher das remote update via imonc. Das geht doch
schon seit einer weile via sfp mithin ein verwandter von ssh. Da ist die
putty-nähe. ;)
Post by Heinz-Peter FaasenAber mal so unter uns: Hast Du Kenntnis, warum das Projekt so sang- und
klanglos im Orkus verschwunden ist? Schließlich hat man sich nach dem
Freiberg-Desaster noch die Mühe gemacht, wieder alles zum DL bereit zu
Freiberg-Desaster? Was war das denn, was war da los???
Post by Heinz-Peter Faasenstellen. Dann den Stecker zu ziehen, ohne jede Erklärung und ein paar
Abschiedsworte, finde ich schon schade und des Projekts unwürdig.
Abschiedsworte? Hab ich NOCH was verpaßt oder ist das so lang her das es
aus der Haltezeit meines nntp raus ist?
Ich weiß auch nix zum ob, wie, wann, warum oder "vielleicht" aber ich
könnte annehmen das ein Grund die Vielzahl an Router-appliances ist die
man heutzutage einfach als iso runter laden kann, auf einen stick oder
CD brennt und davon eine Komplettlösung mitsamt paketmanager und (nicht
vollständiger) auswahl an Extras installieren kann - auf HW die für den
Heimgebrauch ebenfalls nicht unbedingt Taufrisch sein muß.
Beispiele: ipfire, pfsense, opnsense und früher gabs noch ipcop,
monowall u.v.m.
Einige basieren auf Linux (ipfire, ipcop) andere auf einem gehärteten
BSD (die anderen o.g.)
Und als ich vom Echten ISDN; bei dem ich den FLI auch als Anrufmonitor
geschätzt habe; weg "gerissen" wurde (Kündigung T-Kom) habe ich auch
erst mit einer neukonfiguration des FLI gespielt. Als Gateway zwischen
dem Speedport Hybrid den ich nehmen MUSSTE und dem internen LAN.
Aber anrufmonitor allein war zu wenig, jeder bei Änderung nötige
Neustart zu nervig (bei einem zwischen-router) und so bin ich über
ipfire jetzt bei opnsense gelandet.
Läuft auf einem Dualcore Pentium mit 2 GB RAM, hat in dem Alt-PC 3
Netzwerk-Karten und die Platte ist groß genug für einen Proxy und viel
mehr. Neustarten muß der nur bei größeren updates (neuer Kernel oder so)
und ansonsten kann man alles live im System via WebUI ändern.
Prinzipiell könnte man den auch von CD booten und die konfig auf Stick
o.a. speichern damit er wie FLI "statischer" und damit weniger
kompromittierbar ist - was ich pers. aber nie als Vorteil denn mehr als
Hindernis bei Updates angesehen habe.
Und der SPH braucht schon 3 min. für einen Reboot. Das gleiche bei dem
dazwischen fand ich unschön.
So fehlt mir bei opnsense jetzt zwar ein imonc für meine(n)
Linux-Desktop(s) und auch ein gkrellmd als ersatz gibt es dort nicht.
Und etwas wie OAC müsste man auch händisch nach bauen oder Ein
Portal-Setup mit Vouchern u.a. unbegreiflichem einrichten. Da endete der
erste Versuch auch in einer Interface-totalblockade. :-/
Aber es gibt immerhin snmp und interne Traffic-graphs u.v.m. Dazu ist es
opensource, wird weiter entwickelt, es gibt updates und es installiert
sich im grunde so leicht wie ein linux desktop. Stick rein, booten, ein
paar Fragen beantworten und den rest macht man in der WebUI.
Wenn ich das mit FLI vergleiche dann finde ich es immer noch ambivalent.
Einerseits vermisse ich die Geschätzten Vorteile des FLI4L anderseits
ist die Alternative viel bequemer weil alles InSystem erledigt wird.
Komisch ist daran nur das ich offenbar der einzige FLI user bin/war der
imonc/imond nebst telmond als DAS Alleinstellungsmerkmal ansah und
eigentlich immer und überall als erstes einrichtete. Und irgendwer vom
FLI Team meinte dann mal das alle anderen das nicht so sähen, es würde
kaum gebraucht, die meisten nähmen die WebUI des FLI. Okay, fand ich
überraschend aber wenn's dann so ist wundert es mich nicht das der es
nicht in die Version 4 schaffte.
Mir scheint es auch so als ob es da Uneinigkeit oder ??? gibt/gab
zwischen dem Programmierer (? Nico Wallmeier o.ä.) des Windows-Imonc und
dem FLI Team. Aber ob das in irgend einer Weise eine Rolle spielt...
keine Ahnung.
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)