Recent content by czechsys

I don't know how to identify such mail in pmg style logs, but i think too, it's some of those mails from postfix directly. That's why i asked about "myorigin" for masking pmg hostname in "From" Domain (for spf).

With Signing Domain Source: Header Sign Domain: pmg-01.FQDN Red blocks are all the same FQDN

Administrator EMail: root@FQDN 'From' for Admin Mail: Proxmox Mail Gateway <postmaster@FQDN> Sign all Outgoing mail: No /etc/pmg/dkim/domains: #pmg signing FQDN 1 "FQDN" is our email domain. Every test is via the internal mx->pmg->internet mx direction.

That't because i see PMG is using pmghost.FQDN as EHLO for some generated mails and it breaks SPF record: SPF Verification Failed helo pmg-01.FQDN Anyway, tested your suggestion: disabled dkim signing: email sent from client -> mailserver (1. dkim sign) -> pmg -> target enabled dkim...

@Stoiko Ivanov any reply please?

Based on the DMARC analyzators. Because PMG doesn't support changing domains for generated mails by weubi i am looking for the most easiest way to do it without extra configurations on other systems. Target: signing PMG generated emails ONLY Problem: PMG is currenty sending as...

Another bug - when you remove REALM with users mapped, and after it try to remove user: api error (status = 400: unknown realm sub.example.org) Removing user fails.

PDM 1.1.1 tests (based on "Allow changing an LDAP realm to use anonymous search."): domains.cfg: ad: sub.example.org base-dn dc=sub,dc=example,dc=org mode ldaps server1 fqdn1 server2 fqdn2 comment AD authentication user.cfg: user: USER@sub.example.org enable true...

Try this parameter in the nvidia apt repository configuration for SHA1 problem: Allow-Insecure: yes

Option: You can mount nfs via /etc/fstab and use storage -> directory variant on the PVE side.

No, we never used linux bridges for PVE.

There was 2 changes: 1] update PVE8 from 9/2025 (5 hosts) and 1/2026 (2 hosts) to current - to get cluster on the same version 2] added "ovs_options mcast_snooping_enable=false" to vmbr0 - due failing ipv6 in VMs after manual migration So if there isn't some new bug ... I will try...

Hi, the was problem with booting (some) VMs after pve server reboot, shared multipathed iscsi SAN. VM (vg-dorad-prod, bulk start after pve reboot): 2026-04-14T04:10:06.683761+02:00 pve-14 pvesh[3655]: Starting VM 576 2026-04-14T04:10:06.690330+02:00 pve-14 pve-guests[3721]: start VM 576...

Hi, currently are our VMs network dualstack mainly. Only very small number of them is ipv6 only. The problem is currently detected on the dualstack VMs on the PVE 8.4. When doing manual offline migration (gui or ha-manager), some migrated VM's ipv6 doesn't work after boot. When doing automatic...

Busy database with huge number of the cpu cores? Solution: 1] disable HT or 2] don't overallocate nonHT cores to VM+PVE The HT cores aren't for busy/fast/etc workloads, but for idle/low workloads mainly (so you can overallocate low power VMs).