gyptazy23h ago
Adding the new #syslog feature to #PegaProx for #Proxmox clusters during Easter is basically: hiding eggs → finding eggs → realizing some eggs are actually critical alerts

For real, many people asked me for their smaller and mid-sized environments, how to handle remote syslog of their nodes. I had some ideas (some of you may have already found my Rust interpretation of this) but I think having this included in #PegaProx as a centralized management interface makes more sense.

So, PegaProx comes with an own syslog server (ipv4/ipv6, udp/tcp, encrypted/unencrypted support) and is wired to the interface within the resources tab. Providing a quick overview of all your logs and filter options. The next thing is wiring it to the notification system of PegaProx, allowing automated alerting. Might be nice to quickly identify when the quorum got lost - all built-in into PegaProx!

#easter #development #coding #python #opensource #foss #pve #proxmox #proxmoxve #virtualization #vmware #alternatives #free #logging #security #gyptazy #proxmoxdatacenter #homelab #enterprise
Show threadErik Ableson
@gyptazy Cool! Could this also be used as a generic destination for syslogs? I know lots of small shops that have that on their long security compliance list that never gets done
Apr 3 at 6:17pmWeb
Show threadgyptazy18h ago
That's a good question and also an open question I already raised within the PR, when going down deeper the tenancy model. Right now, this is a global cluster admin audit attribute, means this role can view all clusters and their logs. It should probably also stripped down (and limited) by the nodes of the currently selected cluster/tenancy. Right now, everyone can send logs which is okish as we can still limit it by firewall rules, but when it comes to accessing those logs - I'd like to have it but still thinking about aligning the security roles as there isn't any uniq identifier for a VM that belongs to that cluster - and then still questionable if the cluster infra operator should also be able to view the logs on VMs running in that cluster. So, probably limiting to nodes of the select cluster/tenancy and creating a configurable list of items with a new kind of privilege/role that can be granted to view "other items" based on the $preservefqdn name to a user/group... So, yes - my idea is to make this available as a full alternative to other logging solutions. Happy to hear more feedback or ideas 🙂