So ein Eimer:
[Blockierte Grafik: http://www.ayback-technik.de/images/product_images/popup_images/322_0.jpg]
Besser als schnöder Filterkaffee, aber auf Dauer unerträglich...
Beiträge von JCL
-
-
Die hiesige Tchibo-Großk(r)ampfkiste schluckt nur ganze Bohnen und jede Menge widerliche Pulver, u.a. für Milchersatz. Aber aus dem Vorrat erzeugt sie dann min. acht Sorten Gebräu.
-
Es ist vor allem ein Problem hier vor Ort. Zuhause habe ich auch noch einiges im Keller stehen, was man für Tests heranziehen kann.
Aber danke für das Angebot. -
Möglich, aber ausser dem Mainboard bleibt ja kaum noch etwas übrig.
Aktuell gibt es auch keine Hardware-Restbestände mehr. Vor einiger Zeit kam hier der große menschliche Kehrbesen und hat alles, was vermeintlich nicht mehr benötigt würde, der Entsorgung zugeführt. Leider knapp vor meinem Veto.
-
Das dachte ich eigentlich auch. Wobei ich schon mal den Eindruck hatte, dass die EFW stabil(er) lief, nachdem der Haken »verwaltet« entfernt wurde. Leider hatte sich das alleine als nicht ausreichend gezeigt.
In den Protokollen sah ich aber jede Menge Skripte, die sich um das »Wohlbefinden« des Uplinks kümmern. Da es aber zu den Abstürzen jeweils keine Protokolleinträge gab, lässt sich da auch nur schwer ein Zusammenhang bestätigen.
-
Sehr gut. Solche Leute brauchen wir hier. *schlüüüürf*
Und nachher gibt es dann wieder die hausinternen Wettbewerbe im Teebeutelweitwurf. -
So... ein weiterer Tag ohne Ausfall der IPfire-FW.
Und ein paar Erkenntnisse mehr, denn es gab in der Nacht offenbar eine Unterbrechung in der Internet-Anbindung. Soll heissen: aus dem internen Netzwerk war ein IRC-Account online. Gegen 2 Uhr meldete das Programm eine Unterbrechung zum IRC-Server, baute einige Zeit später die Verbindung neu auf und alles lief friedlich weiter.
Ich schaue nachher mal die Log der FW um diese Zeit herum durch und bin gespannt, ob ich etwas Aussagekräftiges finde.
Meine Vermutung wäre, dass die Endian FW auf einen Ausfall der (statischen) Ethernet-Verbindung zum T-Com-Gateway reagiert, nur leider nicht so wie geplant, sondern mit einem Absturz. Ob der Uplink dabei »verwaltet« wird oder nicht, macht offenbar dabei keinen Unterschied. Ich kann nichtmal sagen, ob der Switch zwischen FW und Gateway, das Gateway selber oder irgendwas auf T-Com-Seite da regelmässig mal Probleme macht, denn diese Komponenten liegen allesamt nicht in meiner Obhut.
Sollte ich noch Massgebliches finde, werde ich weiter berichten.
-
Geht das Ganze auch mit Tee?
Moinsen. -
Zitat von "Sabine"
… wenn es nicht so viele Idioten gäbe, die von nichts Ahnung haben aber alles kaputt kriegen!
Soviel also zu »idiotensicher«. Es werden schneller verbesserte Idioten als verbesserte Systeme entwickelt... -
Das erinnert mich an graue Vorzeiten, wo im Macintosh SE zwei Disketten in ein 3.5"-Laufwerk versenkt wurden... Totalschaden. Und heute kostet wohl selbst ein BlueRay-Brenner nur noch ein Bruchteil...
Ich geniesse dann noch mal die ruhige Zeit hier in der Einflugschneise des Airport Hamburg. Herrlich.
-
Aktueller Zwischenstand: IPfire stabil seit 24 Stunden. Muss noch nichts heissen, verschaffte mir aber immerhin einen ruhigeren Morgen.
-
Ich treffe normalerweise den PC an, wenn er schon Stunden vorher »erfroren« ist. Zu dem Zeitpunkt ist es dann schwer zu sagen, was in den Nacht passiert ist. Auffällig warm ist der PC jedenfalls nicht, Lüfter laufen und nach einem Neustart macht die FW auch unbekümmert weiter, zumal der Rechner hier im hohlen Fußboden residiert. Dieser ausgesprochen grußzügige Hohlraum ist gut belüftet, ziemlich staubarm und vermutlich der derzeit kälteste Bereich des Gebäudes...
IPfire läuft noch, aber die Probleme waren auch meistens in den Nacht aufgetreten. Also abwarten, Tee trinken.
-
Die Idee hatte ich auch schon. Über Nacht via ssh eingeloggt, top offen gelassen. Beim Ausfall lief laut top nichts Auffälliges. Leider.
-
»Been there, done that.« – auf der Kiste läuft jetzt testweise mal ein IPfire, über die ich auch gerade online bin. Die Endian-Firewall finde ich zwar deutlich schöner im GUI, Umsetzung und Umfang, aber das ist ja zunächst nicht unbedingt das ausschlaggebende Kriterium.
Ich werde dann mal berichten, wie sich das System über die nächsten Tage verhält.
-
Leider finde ich keine dokumentierten Mindestanforderung für die EFW Community. Allerdings für die Endian UTM Software:
ZitatKompatibel mit Intel x86 (mindestens 500 MHz, 1 GHz empfohlen), z. B. Prozessoren der Marken VIA, AMD Athlon, Athlon 64, Opteron, Intel Core 2 Duo, Xeon, Pentium und Celeron
Das klingt eigentlich danach, als sollte der Prozessor und sein Befehlssatz grundsätzlich kein Problem seien. Theoretisch.Bliebe noch die Frage, welcher Prozess evtl. solche Befehle anschieben sollte, der obendrein auch kleinen Log-Eintrag hinterlässt. Bislang hatte ich hier Snort in Verdacht, insbesondere nach Lesen dieses Threads. Inzwischen müsste ich aber alles, was zu Snort gehört, deaktiviert haben.
Die Netzwerkkarten hatte ich auch schon verdächtigt, nachdem ich hier schon einiges gelesen hatte. Daher wurden, wie schon geschrieben, die beiden 3com-NICs gegen Intel-NICs getauscht.
-
Nein, am BIOS war ich (ausser an den Startoptionen, Booten via CD) nicht weiter dran. Ich meine aber, dass die letzte BIOS-Version installiert sei. Außerdem würde ich glauben, dass BIOS-bedingte Probleme eher grundlegend seien und früher auftreten müssten. Aber ich werde das noch einmal prüfen – obwohl der PC als Arbeitsplatz ja vorher problemlos tat. Danke für den Tip.
»Virus Warning« ist dort im BIOS nicht vorhanden, meine ich. Schaue ich aber auch noch mal nach.
Wenn ich richtig informiert bin, würde das »Virus Warning«-Feature Schreibvorgänge in den Bootsektor und die Partitionstabelle verhindern oder zumindest melden, was allerdings die Installation der EFW schwierig gemacht hätte. -
Ja, die Kiste steht dann komplett still. Kein https, kein ssh, kein ping, keine serielle Verbindung, nix. Fährt man die EFW wieder hoch (harter Reset), kann man in den Diagrammen z.B. für CPU-Auslastung für den entsprechenden Zeitraum ein Loch sehen.
Der PC ist vorher längere Zeit ohne Probleme als Arbeitplatz gelaufen, wurde dann aber aufgrund seiner Ausstattung dann doch endlich mal ausgemustert. Die Platte darin ist ebenfalls beinalt, 10 GB groß, aber zeigt aber auch via smartctl und badblocks keinerlei Probleme. Wie schon geschrieben: auch memtest zeigt bei den 512 MB RAM keine Auffälligkeiten.
Ich werde wohl am Montag Morgen auf das System probeweise mal IPfire 2.5 installieren und beobachten. Sollte es dort ähnliche Erscheinungen geben, würde ich doch die Hardware als Ursache sehen.
-
Offenbar ist die Kiste zwischenzeitlich wieder tot. Mehr kann ich leider erst am Montag vor Ort sagen, aber ich wundere mich schon, woran das liegen könnte. Wie schon gesagt, die Logs geben da bislang nichts her, Memtest übrigens auch ohne Fehler.
-
Derzeit macht der alte PIII seine (wenigen) Aufgaben ansonsten ganz ausgezeichnet – denn viele der Funktionen, die die EFW bietet, werden (derzeit) dort überhaupt nicht benötig. Aber es war ein guter Anlass, sich die EFW mal genauer anzuschauen.
Alles, was da derzeit benötigt wird, ist NAT und FW, der DNS-Proxy und ein bisschen Squid/HAVP für zwei Windows-Plätze. Dafür langt das System vollkommen aus. Alles weitere schaue ich mir dann in ruhigen Minuten mal an, wenn sonst keiner mehr im Netz ist. Sollten dann mehr Dienste interessant werden, kann das System immer noch auf größere Hardware umziehen.
Das Einfrieren des Systems hat aber m.E. nichts damit zu tun, ob das System mit 500 MHz oder mehreren GHz arbeitet. Aktueller Stand übrigens: nach der Abschaltung der Einstellung »Anti-Spyware« hat das System die Nacht schon mal wieder überlebt.
Ich vermute mal, dass es für die Version 2.3.1 noch keinen Release-Zeitpunkt gibt, richtig? Nach dem, was ich hier bislang gelesen habe, ist die Community-Version mit Updates einzelner Pakete überhaupt nicht versorgt.
-
Auch ich habe das Problem, dass die EFW 2.3 Community immer wieder einfriert, ohne dass in den Logs brauchbare Informationen zu finden wären. Das System* hängt an einem Gateway zu einer T-Com-Standleitung per Ethernet mit fester IP.
Das IDS Snort habe ich bereits deaktiviert. Leider fror das System dennoch regelmässig nachts ein.
Die Netzwerkkarten hab ich zur Sicherheit einmal komplett getauscht.
Für den Uplink habe ich mal das Häkchen »Verwaltet« entfernt.
Für den DNS-Proxy habe ich die Einstellungen »Anti-Spyware« deaktivert, die wohl auch auf das Snort-Projekt zurückgehen.
Resultat: stabiles System für drei Tage.Kaum hatte ich die Einstellung »Anti-Spyware« wieder aktiviert, fror das System wieder des nächtens ein – ohne sinnvolle Logeinträge gegen 3:30 Uhr (Update der Snort-DNS-Liste sollte lt. Webinterface gegen 1:25 Uhr erfolgen; einen Log-Eintrag dazu finde ich allerdings nicht.). Hat jemand ähnliche Erfahrungen gemacht?
Ich habe die o.g. Einstellung wieder deaktiviert und beobachte mal, ob jetzt alles stabil läuft.
--
*) Leider »nur« ein alter PIII/500 mit zwei NICs, 512 MB RAM und winziger Platte. Ein auf die Schnelle aufgesetztes Notfallsystem, nachdem eine andere FW-Appliance Totalschaden hatte.