Kann ich jetzt die 2.4.0 neu installieren, auf die 2.4.1 updaten und die Daten aus meiner jetzigen Installation ohne Probleme importieren?
Ja. Ggf. noch /etc/businfotab anpassen wegen der Netzwerkkarten. Sollte bei identischer Hardware aber entfallen.
Woher soll man eigentlich wissen, dass man besser zuerst die 2.4.0 installiert und dann updatet?
Entweder aus eigener leidvoller Erfahrung lernen oder zuvor auf bugs.endian.com schlaumachen.
Du könntest mit einem Partitionierungs-Tool wie z.B. gparted mehr Platz schaffen. Das würde ich allerdings nicht unbedingt in einer Produktiv-Umgebung empfehlen.
So wie es aussieht, hast Du die 2.4.1 direkt installiert. Da werden keine Swap-Partition und auch keine Startfestplatte angelegt. Ich empfehle stattdessen die Installation der 2.4.0 und anschliessendes Upgrade auf 2.4.1.
Eine Swap-Partition wäre bei Deiner gegenwärtigen Speicherauslastung ohnehin ratsam.
Gruß
Joachim
Schau mal hier:
http://bugs.endian.com/view.php?id=3314
Ist wohl kein unbekanntes Problem
Gruß Sabine
Danke für den Hinweis, Sabine.
Mein Problem ist aber nicht der smtpscan, sondern der POP3-Proxy, bzw. Spamassassin. In den Spamfilter-Einstellungen des POP3-Spamfilters gibt es die Option "Prüfsummenbasierte Spamerkennung aktivieren (pyzor):". Dort habe ich auf der neuen EFW kein Häkchen und der Dienst ist in der Übersicht auch angehalten.
Auf einer anderen EFW habe ich dort auch kein Häkchen, aber der Dienst läuft trotzdem (zumindest laut Systemstatus).
Gruß
Joachim
Hallo Leute,
vergangenes Wochenende bin ich mit einer EFW auf neue Hardware umgezogen. Nachdem ich das Backup der alten Maschine auf die neue eingespielt hatte und die businfotab wegen der Netzwerkkarten entsprechend angepasst hatte, lief alles wieder wie gewünscht.
Was mich jedoch etwas stutzig macht ist, dass der Pyzor Spamfilter in den Systemstatusinformationen den "ANGEHALTEN"-Status hat. Auf der alten EFW lief der Dienst, und das, obwohl er auch dort nicht aktiviert war.
Ich möchte Pyzor gar nicht nutzen, mich wundert nur, dass er auf allen meinen anderen EFWs läuft, ohne aktiviert zu sein. Gab es hier evtl. eine Korrektur, die mittels efw-upgrade eingeflossen ist?
Grüße
Meisen
postfix/smtp[12521]: 0A80E204002: to=, relay=127.0.0.1[127.0.0.1].......
Fehlt da nicht etwas, z.B. to=, relay=127.0.0.1[127.0.0.1]:10024
Hier übergibt Postfix die Mail an Amavis. Läuft Dein SMTP-Proxy transparent?
Kann man im Log noch was einstellen oder ist das ev. ein BUG?
Sieht bei mir genauso aus. Hat mich bisher nicht gestört.
Das zweite Problem sind Fehlermeldungen vom postfix:
postfix/cleanup[12519]: warning: database /etc/postfix/relay_domains.db is older than source file /etc/postfix/relay_domains
postfix/cleanup[12519]: warning: database /etc/postfix/recipient_bcc.db is older than source file /etc/postfix/recipient_bcc
postfix/cleanup[12519]: warning: database /etc/postfix/sender_bcc.db is older than source file /etc/postfix/sender_bcc
Ich weiss zwar was die Fehlermeldung bedeutet, aber wieso sie auftritt ist mir nicht klar.
Das rührt daher, dass Postfix chrooted läuft, hat aber keinen Einfluss auf die Funktionalität. Nach einem Neustart der EFW sollten derlei Meldungen verschwunden sein.
Gruß
Joachim
In welchen Logs sollte ich da nachschauen?
Unter /var/log/messages sollte sich dieser Eintrag befinden:
sudo: nobody : TTY=unknown ; PWD=/home/httpd/cgi-bin ; USER=root ; COMMAND=/usr/local/bin/setddns.pl -f 2
Welche Version nutzt Du? In der 2.4.1 gibt es einen Bug in der Datei /usr/local/bin/setddns.pl
Dort die Zeile
if ($settings{'SERVICE'} = 'zoneedit')
ersetzen durch
if ($settings{'SERVICE'} eq 'zoneedit')
Danach in der Weboberfläche ein Update durchführen, dann sollte es passen.
Gruß
Joachim
Kannst Du mir verraten wie Du den clamd wieder zur Mitarbeit überredet hast? Ich habe hier im Moment das Gleiche Problem.
Siehe dazu meine Antwort in Deinem anderen Thread.
Ein Updateversuch von ClamAV nach der Anleitung von http://suckup.de/blog/2010/01/3…dnsmasq-update/ mit den aktuellen Dateien verlief negativ. Gibt es für die clamd aktualisierung unter Endian vielleicht eine andere Anleitung?
ClamAV kümmert sich ganz gut um sich selbst, wenn der Aktualisierungszeitplan aktiviert ist. Vor einigen Wochen gab es aber mal eine laut Protokoll "malformed database", die den clamd killte. Seitdem läuft es aber wieder störungsfrei.
Gruß
Joachim
Hallo Ralf,
dieses Problem hatte ich kürzlich auch, als das Update der Virensignaturen nicht korrekt lief. Dadurch hat der Clamd innerhalb kurzer Zeit tausende von Warnmails erzeugt, die aber nicht in der Mailqueue gelandet sind, sondern wie bei Dir unter /var/amavis eine entsprechende Anzahl an amavis-* Ordnern erzeugt hat.
Meiner Meinung nach entsprechen diese Ordner normalerweise der Anzahl der amavisd-Prozesse. Gibt es -aus welchen Gründen auch immer - mehr Ordner als Prozesse, arbeitet Amavis und damit auch Postfix nicht mehr korrekt.
Ich habe dann Amavis gestoppt, alle amavis-* Ordner gelöscht und dann wieder gestartet. Anschliessend wurde die Mailqueue mit postfix flush wieder korrekt abgearbeitet. Keine Mail ging verloren.
Gruß
Joachim
[...]Da gibt es das File /etc/businfotab wo ich fündig geworden bin. Dort hab ich die eth0 - eth4 gefunden ich nehme an mit den HW-Adressen der Netzwerk Port (ich hoffe ich liege da richtig) und auch die eth5 - eth9 mit anderen HW-Adressen.
Tja, ich denke wenn man das alles gerade biegt (wo bei ich nicht weiß ob das die einzigen 2 stellen sind wo das Problem auftaucht) müsste eigentlich die br0 mit der IP wieder auf die eth0 zeigen und diese wiederum auf eine existierende HW-Adresse. Dann sollte man wieder rein kommen in das web-Frontend.
Hallo Geri,
Du bist auf dem richtigen Weg. eth0 - eth4 sind die NICs der alten Hardware, die mit der Rücksicherung des Backups übernommen werden. Eth5 - eth9 sind die NICs der neuen Hardware. Du kannst die alten NICs in der businfotab löschen und die neuen NICs entprechend umbenennen. Nach einem anschliessenden Neustart läuft die EFW wieder wie gewohnt.
Probleme mit anderen Hardware-Einstellungen aus dem Backup konnte ich bei meinem Umzug nicht beobachten.
Gruß
Joachim
So, nach intensiver Recherche konnte ich das Problem nun selbst lösen.
Der durch das Update korrumpierte clamd hat ca. 9000 Mails über seinen inaktiven Status abgesetzt. Nach 6000 Mails hat Amavis dann abgewunken und die Zustellung eingestellt. Nachdem ich dieses Malheur bereinigt habe, hat Amavis auch wieder die "echten" Mails in der Queue abgearbeitet.
Gruß
Joachim
Hallo zusammen,
meine efw will seit gestern Morgen keine Mails mehr versenden, d.h. die Nachrichten laufen in der Mailqueue auf, mit dem Hinweis, die Zustellung sei temporär gestört, weil keine Verbindung zu 127.0.0.1 hergestellt werden konnte.
Ich vermute dahinter Amavis, aber weder ein Neustart von amavisd noch der ganzen efw schafft Abhilfe. Ich habe sowohl über die Weboberfläche wie auch über die Konsole versucht, die Mailqueue zu flushen. Leider ohne Erfolg.
Kann mir jemand einen Tipp geben, wie ich die Mails rausbekomme?
Danke & Gruß
Joachim
cd /usr/share/clamav/ rm -Rf clamav-* rm main.cvd rm daily.cvd curl -O http://db.local.clamav.net/bytecode.cvd freshclam /etc/init.d/amavisd restart restartclamav /etc/init.d/amavisd restart
Das hatte ich mir zunächst auch im englischsprachigen Forum abgeschaut. Das Problem war, dass die bytecode.cvd danach immer noch nicht in Ordnung war und so das Starten des clamd verhindert hat. Nachdem ich die Datei ganz gelöscht hatte, ging es wieder. Seit vergangener Nacht, bzw. heute Morgen ist die Datei laut Update-Protokoll wieder in Ordnung.
Mit den Updates an sich hatte ich zu keinem Zeitpunkt Probleme.
Gruß
Joachim
P.S. Es lohnt sich, nach obiger Aktion einen Blick in die Mailqueue zu werfen, falls man einen Mailproxy betreibt. Bei mir hatten sich innerhalb 1/2 Tages > 3000 Mails vom Clam-Daemon angesammelt. :?
Also bei mir lag's an der bytecode.cvd, die laut Update-Protokoll "malformed" ist.
Nachdem ich diese gelöscht hatte, liess sich auch der clamd wieder starten.
Gruß
Joachim
freshclam restartsquid.py --force -d restartclamav.py --force –d
Ich habe zwar keine Probleme mit dem HTTP-Proxy, aber der CLAMD lässt sich bei mir nicht mehr starten. Auch nicht nach Ausführung obiger Befehle. Ein Neustart schafft ebenfalls keine Abhilfe.
Das Problem tritt aber nur bei einer Maschine auf, die direkt mit der 2.4.1-ISO installiert wurde. Bei einer anderen, die von 2.4.0 auf 2.4.1 upgedated wurde, besteht das Problem nicht.
Hat noch jemand 'ne Idee?
Gruß
Joachim
Welche Version der EFW hast Du denn im Einsatz? Ich hatte bei der 2.4.0 auch regelmässig das Problem, dass sich der POP3-Scanner verabschiedete. In den Protokollen ist das nicht ersichtlich, aber der entsprechende Dienst steht auf "defunct".
Zunächst habe ich mir damit beholfen, den p3scan jede Stunde per Cronjob neu starten zu lassen. In der Version 2.4.1 ist das Problem glücklicherweise verschwunden.
Dieses schöne Tool gibt es hier auf der Startseite unter „ efw-monitor „ 8-)
Gruß Sabine
Hab's gefunden :oops:
Der Speiche hält sich im Augenblick bei 3,25 GB, keine Änderung bis jetzt, trotz reichlich surfen ( habe so 3500 bis 12500 Verbindungen laufen )
Gruß Sabine
Wo gibt es denn das nette Tool, von dem Du den Screenshot gemacht hast?
Ist eigentlich schon jemand aufgefallen, dass die Installation der 2.4.1 ISO keine Swap-Partition mehr anlegt?
Gruß Joachim
Moin,
die Speicherauslastung liegt derzeit bei 3,2 GB ! ! :o
Noch ist keiner am surfen, mal sehen was passiert wenn es wieder richtig abgeht.
Ich habe jeder Nacht eine Spitze bei der Prozessorauslastung ? ?
Heute Nacht um 4 Uhr lag das ganze bei fast 60 % ! !
Ich habe nachgesehen ob vielleicht Snort oder der Virenscanner sich upgedatet habe, das war nicht der Fall
und sonst habe ich auch nichts was sich ein mal Nachts updatet, komisch ? ? ?Gruß Sabine
Von meine verbauten 4 GB RAM gönnt sich die EFW zwischenzeitlich auch 3,5 GB. :o
Und ich hatte heute Nacht auch eine fast 60%ige CPU-Auslastung. Ein Blick ins Protokoll zeigt mir um 3:52 Uhr zwei dafür in Frage kommende Jobs. restartsarg.py und cron.monthly. Ich tippe mal auf den Cron-Job.
Gruß Joachim
Hier mal ein Link zu einen Beitrag hier im Forum
Da habe ich mich vielleicht etwas missverständlich ausgedrückt. Ich möchte keine Client-Router-Verbindung herstellen (was auch bei mir bereits einwandfrei läuft), sondern Router-Router.
Nun stellt sich mir z.B. die Frage, ob ich auf beiden Routern Zertifkate erzeugen und diese dann gegenseitig austauschen muss, oder ob es reicht, z.B. nur auf der EFW eines zu erstellen und dieses dann an der Gegenstelle zu importieren.
Hast Du in der Hinsicht auch schon Erfahrung?
Gruß
Joachim
So, dann schreibe ich hier mal den ersten Beitrag, auch wenn das Thema vielleicht eher zu VPN, IPSec, etc. gehört. 
Also, ich stelle bisher diverse VPN-Tunnel zu meiner EFW per IPSec mit preshared keys her. Nun würde ich gerne die Sicherheit etwas erhöhen und deshalb auf die Authentifizierung mit Zertifikaten statt PSK umsteigen.
Habe am Wochenende mal versucht, mich in die Problematik einzulesen. Es sind aber noch einige Fragen offen geblieben, die nur unzureichend oder gar nicht beantwortet wurden.
Deshalb wollte ich mal anfragen, ob hier jemand erfolgreich einen VPN-Tunnel mit Zertifikat am laufen hat und mich gerne an seiner Erfahrung teilhaben lassen möchte?
Danke schonmal & Grüße
Joachim
