ClamAV Frage [GELÖST]

[TuXi]

Der Lügenbold bist du MLan..

Nochmal:
Unterlasse bitte deine Unterstellungen, bevor du deinen Beitrag veröffentlichen konntest.
Habe ich noch die Edit Funktion genutzt und entsprechend auch veröffentlicht und die Edit Funktion steht sowohl mir als auch den anderen zu.
Und wenn du ein Problem damit haben solltest, Pech.

Ganz egal ob du mein Edit akzeptierst oder nicht, ich habe meinen Beitrag entsprechend vor deinem Beitrag noch editiert und fertig.

[OlliTheDarkness]

Es war einmal ein Peter Hase , diesem drücke sehr die Blase...
Und die Moral von der Geschicht, Tuxi zügel dich und mach kein Mist.

P.S
Fahr nen gang runter, ansonsten machst dir nicht nur die Community zum Feind.
Würde drüber nachdenken...

[TuXi]

Was soll diese Anspielung mit Peter Hase?!
Ich bin komplett neu hier und befasse mich noch nicht solange mit KeyHelp sondern erst seit September.

Und MLan ist der jenige, der einen gang runterfahren sollte.
Wenn er ein Problem hat, dass man kurz vor einem neuen Beitrag (MLan' Beitrag), seinen eigenen nochmal editiert.
Ist es sein Problem und nichts meins. Das was er zitieren wollte, lautet nun mal anders und mehr ist dazu nicht zu sagen(schreiben).

Ich habe wollte erst darstellen, dass MLan unwahre Texte (Lügt) schreibt und das von Alexander wahr ist, habe ich aber nun mal anders formuliert und zwar so.
Dass MLan Beiträge nicht unwahr (Nicht lügt) sind sondern nicht zu meiner Situation zutreffend ist, sondern die von Alexander.

Und zu dem:
Dass es hier nicht um meine vServer geht, da hat Alexander schon in einem Thema Beitrag schon was dazu geschrieben und habe ein Satz davon auch hier zitiert.

Von daher mache ich ganz bestimmt keinen "Mist" und wenn, dann nur auf dem Klo

@MLan
Um das ganze mal jetzt zusammenzufassen und kurz zufassen, da ich dich ganz bestimmt nicht als Lügner hinstellen wollte.
Habe ich genau aus dem Grund auch meinen Beitrag geändert, aus dem Grund bin weder ich noch du ein Lügenbold
Und da ich mich jetzt praktisch entschuldige, sollte das auf der anderen Seite auch kommen.

Weil man editiert seinen Beitrag niemals so wahlkürlich / willkürlich oder was auch immer.. Man sollte bevor ein neuen Beitrag auch erstmal nochmal vor dem "Absenden" überprüfen, ob nicht noch kurzfristig Änderungen gibt.

@OlliTheDarkness
Ach ja noch was weiteres an dich, dein allerersten beitrag hatte ich nicht so verstanden, habe jetzt in diesem Moment aber nochmal durch gelesen und jetzt habe ich es verstanden.

Ich möchte aber zu gerne wissen, warum das aber ausgerechnet nur bei der Netzwerk Installation passiert.
Dass der Virenschutz deaktiviert wird (Autostart bei einem Bootvorgang) und nicht über ein Image, was von einem Anbieter selbst gebaut wurde.

Bei einem Netinstall(CD / DVD von Debian): systemctl disable clamav-daemon
Über ein Image von seinen Anbieter: systemctl enable clamav-daemon

Eventuell versteht man mein Anliegen jetzt auch etwas besser.

Zu meine vServer habe ich in viewtopic.php?f=2&t=10992&start=15 was geschrieben.

[tab-kh]

Basis für die Entscheidung "enable" oder "disable" ist die Ausgabe des Befehls "free -b" und hier die Angabe der "total" Spalte.

Weils hier so schön dazupasst: Ich habe aktuell auch einige Probleme mit einem netcup vServer mit 48 GB RAM.
Installiert war Debian 11 Minimal Image von netcup.

Bei der Installation von Keyhelp vor 2 Wochen (28.11) wurde hier ausgeführt:

Code: Select all

  exec  | systemctl disable clamav-daemon
          Synchronizing state of clamav-daemon.service with SysV service script with /lib/systemd/systemd-sysv-install.
          Executing: /lib/systemd/systemd-sysv-install disable clamav-daemon
          Removed /etc/systemd/system/multi-user.target.wants/clamav-daemon.service.

obwohl (Stand heute)

Code: Select all

# free -b
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:50532970496  2006646784 47697248256     8679424   829075456 48089710592
Swap:              0           0           0

Edit: Könnte es mit der Spracheinstellung zusammenhängen?

[TuXi]

Basis für die Entscheidung "enable" oder "disable" ist die Ausgabe des Befehls "free -b" und hier die Angabe der "total" Spalte.

Weils hier so schön dazupasst: Ich habe aktuell auch einige Probleme mit einem netcup vServer mit 48 GB RAM.
Installiert war Debian 11 Minimal Image von netcup.

Bei der Installation von Keyhelp vor 2 Wochen (28.11) wurde hier ausgeführt:

Code: Select all

  exec  | systemctl disable clamav-daemon
          Synchronizing state of clamav-daemon.service with SysV service script with /lib/systemd/systemd-sysv-install.
          Executing: /lib/systemd/systemd-sysv-install disable clamav-daemon
          Removed /etc/systemd/system/multi-user.target.wants/clamav-daemon.service.

obwohl (Stand heute)

Code: Select all

# free -b
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:50532970496  2006646784 47697248256     8679424   829075456 48089710592
Swap:              0           0           0

Edit: Könnte es mit der Spracheinstellung zusammenhängen?

Danke!
Damit bin ich jetzt nun nicht der einzige!!

Aktivier es einfach im KeyHelp Panel.

Ich teste das aber mal

Edit:
Also an der System Sprache(KeyHelp Einstellung bei der Installation Bezug auf die Sprache) kann es schon mal nicht liegen.
Also nein und bei mehr als 2GB liegt es auch nicht am Arbeitsspeicher

[tab-kh]

Danke!
Damit bin ich jetzt nun nicht der einzige!!

Aktivier es einfach im KeyHelp Panel.

Ich teste das aber mal

Edit:
Also an der System Sprache(KeyHelp Einstellung bei der Installation Bezug auf die Sprache) kann es schon mal nicht liegen.
Also nein und bei mehr als 2GB liegt es auch nicht am Arbeitsspeicher

Ja, aktivieren im Keyhelp Panel war auch meine "Lösung". Ich bin mir auch ziemlich sicher, dass ich das gleich nach der Keyhelp-Installation vor zwei Wochen auch so gemacht habe. Gesehen dass der Haken fehlt und ihn einfach gesetzt, wenn auch ohne zu wissen was das dann außer dem Virenscan der E-Mails noch so bewirkt. Da habe ich zu dem Zeitpunkt überhaupt nicht drüber nachgedacht, war sogar der Meinung, dass der Haken wohl anfangs grundsätzlich nicht gesetzt ist und aktiv selbst gesetzt werden muss. Der war auch mit Sicherheit gesetzt bis irgendwann gestern im Lauf des Tages. Ob der Neustart des Servers gestern der Zeitpunkt der Änderung ist oder ob es schon vorher passiert ist, lässt sich sicher leicht feststellen, habe es aber noch nicht abgeglichen.

Den Spracheinfluss habe ich deshalb nicht völlig ausgeschlossen, weil es natürlich auch sein könnte, dass hier bei der Ausgabe von "free -b" eventuell die Zeile mit "Mem:" gesucht und ausgewertet wird. Die Zeile mit "Speicher:" wäre dann natürlich außen vor.
Aber ich halte es auch für eher unwahrscheinlich. Zudem habe ich einen älteren Server mit Debian 10, der ebenfalls die selbe deutsche locale-Einstellung hat. Allerdings zeigt der bei free -b komischerweise dann doch "Mem:" an und nicht "Speicher:". Also meine funktionierenden Server zeigen alle "Mem:" und der nicht funktionierende "Speicher:" Allerdings kann man von vier Servern jetzt nicht unbedingt auf die Allgemeinheit schliessen

[TuXi]

Also Sprache und Arbeisspeicher scheiden generell zumindestens bei mir aus, es muss irgendwas anderes außer free -b und eventuell die Sprache sein.
KeyHelp überprüft wahrscheinlich nicht nur free -b bei der Installation.

Oder etwa doch? @Alexander
Sobald du mit dem nächsten Update für KeyHelp fertig bist, wäre sehr nett von dir dann, wenn du auf das ganze mal ein Auge wirfst.
Das beobachten immerhin schon 2 Personen, sollte also nicht unbedingt mehr ein Einzelfall sein.

[Alexander]

Hab die Ursache gefunden. Danke für die Ausgabe von "free -b" .

Die Sprache war es nicht, soviel kann ich sagen - ein Leerzeichen war der Übeltäter . Hab es nun quasi als "Last-Minute" Änderung noch ins heute kommende 21.3 update gepackt.

---

Für Interessierte:

In der RegEx hab ich zwingend nach einem Leerzeichen nach dem ":" nach Speicher/Mem oder was auch immer geschaut. Wenn der RAM aber sehr groß bemessen ist, steht da überhaupt kein Leerzeichen mehr. Damit schlug der Regex fehl und die tatsächliche RAM Größe konnte nicht ermittelt werden.


Besten Dank an alle Beteiligten!

[TuXi]

Ich habe deinen Beitrag dann als Lösung / gelöst markiert Alexander
Von einem Bug bin ich aber überhaupt nicht davon ausgegangen, dass es ein gegeben hat.

[tab-kh]

Danke auch von mir. Ich war schon kurz davor den Server einfach nochmal neu aufzusetzen.

[MLan]

Hab die Ursache gefunden. Danke für die Ausgabe von "free -b" .

Für Interessierte:

In der RegEx hab ich zwingend nach einem Leerzeichen nach dem ":" nach Speicher/Mem oder was auch immer geschaut. Wenn der RAM aber sehr groß bemessen ist, steht da überhaupt kein Leerzeichen mehr. Damit schlug der Regex fehl und die tatsächliche RAM Größe konnte nicht ermittelt werden.

Oder die Abfrage umbauen
Angabe in KB

Code: Select all

cat  /proc/meminfo |head -n1 |awk '{print $2}'

[TuXi]

Da einfach nur kein Leerzeichen mehr war, ist ein umbauen in meine Augen überflüssig.
Und wurde auch wie ich den Beitrag von Alexander entnehmen kann, schon in der heutigen kommende Version behoben.

Und könnte jeder Zeit jetzt veröffentlicht werden.