Das Problem das der Agent nicht auf IPv6 hört hatte ich auch.
Hierzu einfach die Datei "/opt/omd/sites/<deinesite>/etc/init.d/agent-receiver" um eine Listen Anweisung auf deine IPv6 Adresse ergänzen.
Im Original sieht das so aus:
[....]
gunicorn -D -p $PIDFILE \...
Ich habe ein simple Regel zum testen erstellt.
------------------------------------------------
Regel: Force to Quarantine
Aktionsobjekte:
- Notify Admin
- Quarantine
Von:
QuarantineSenderList
welche folgenden Regex beinhaltet:
web.*@domain.de
------------------------------------------------...
Ich habe eine Regel auf welche per Regex ein bestimmtes Schema Absenderadressen, hier primär Kontaktformular adressen von Webseiten , in die Quarantäne schickt.
Ist da mal eine legitime Adresse bei wird die per Whitelist auf die User Whitelist hinzugefügt. Allerdings scheint diese nicht zu...
Noch eine Anmerkung. Gebe ich direkt auf den Datastore dem User DatastoreAudit Rechte geht es. Allerdings bin ich mir noch nicht sicher ob damit die Trennung zwischen verschiedenen Usern gewahrt bleibt. Muss ich wohl testen.
Der Fehler bleibt aber auch wenn ich das Recht DatastoreAudit zum Namespace hinzufüge.
proxmox-backup-proxy[1094]: GET /api2/json/admin/datastore/PBS-DataStore/status: 403 Forbidden: [client [192.168.1.1]:47284] permission check failed
Gilt denn ein Recht welches ich für einen Namespace setze...
Interessant. Ich nutze das Recht DatastoreBackup nur aber bisher nur auf dem Datastore direkt und da klappt es ohne Probleme. Aber ich teste es gleich noch einmal auf dem Namespace mit DatastoreAudit
Ich teste gerade die Namespace Funktion vom neuen Backup Server und bin auf ein Problem gestoßen.
Ich habe ein Datastore mit mehreren Namespaces angelegt und dann über Konfiguration => Berechtigungen => Rechte einen Test User für einen Namespace angelegt mit dem Recht DatastoreBackup...
Also ich hatte mir den Ubuntu Mainline Kernel (https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.15.33/) per GIT gezogen und mit der Config vom PMG compiliert. Der Kernel lief auch problemlos. Da Unbound sofort startet sobald ich beim booten einen "nicht pmg" Kernel auswähle würde ich aktuell...
Ja, Apparmor deinstallieren hilft natürlich und wurde nun auch gemacht. Es ist jedoch schon interessant das der Fehler nur mit dem PMG Kernel auftritt. Selbst mit dem Ubuntu Kernel scheint das Problem nicht vorhanden zu sein.
Ich habe jetzt noch einmal weiter getestet. Es muss irgendwas, vielleicht ein patch, vom pmg Kernel sein. Ich habe auf der VM nun den Vanilla Kernel 5.17.2 mit der .config vom 5.15 pmg Kernel compiliert und getestet. Mit dem 5.17.2 Kernel läuft Unbound und clamav-freshclam in Verbindung mit...
Ein Nachtrag habe ich noch.
Das Problem tritt mit dem Original Debian Kernel nicht auf. Sobald ich auf der gleichen Maschine den Debian Kernel starte läuft unbound mit Apparmor ohne Problem.
Genau dies Problem habe ich auch festgestellt.
Problem ist hier das Apparmor eingreift. Allerdings tritt das Problem erst auf wenn man proxmox-mailgateway installiert.
systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
kernel: [ 902.103997] audit: type=1400...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.