VortexPanel v3.4.9 — Release Summary

Mail actually delivers now
Account, domain, and forwarding management always wrote correctly to Postfix's lookup tables — but nothing ever told Postfix to use them. virtual_mailbox_base, virtual_uid_maps, and virtual_gid_maps shipped empty, so no mail was ever actually delivered to a mailbox regardless of what the panel showed. New /api/mail/setup configures the full chain — vmail system user, Postfix's virtual maps, and delivery via Dovecot LMTP rather than Postfix writing maildirs directly (which is the classic cause of "delivered but invisible in IMAP"). Also fixed a related bug: the panel stored password hashes in its own file, which Dovecot never read, so even a correctly-created account couldn't authenticate — deleting an account or resetting its password had no real effect either. Verified with an actual message sent, delivered, and read back via IMAP.

Kernel live patching.
VortexPanel can't implement this itself — it requires each provider's own binary-diffing toolchain per kernel build. Instead, this detects, installs, and reports real status for the two providers that actually exist: Canonical Livepatch (free, Ubuntu-only, ~5-10% CVE coverage) and TuxCare KernelCare (paid, covers all 9 supported distros, far broader coverage). Surfaces reboot_required and pending kernel packages, since that's exactly the blind spot live patching exists to close.

Fixed
Fedora was silently broken across 12 install scripts. Reviewing a community DNS module surfaced a real bug in my own earlier RHEL-family work: detection read $ID_LIKE alone, but Fedora — being the upstream of the RHEL family rather than a derivative — ships no ID_LIKE field at all. On real Fedora, this produced an empty string matching neither the Debian branch nor the RHEL branch, so nginx, Caddy, PHP, BIND9, Fail2ban, and Apache2 installs would silently do nothing there. Fixed to check $ID and $ID_LIKE together, verified against real Fedora 43 /etc/os-release output.