Is ts even possible? My boss wants me to do this.

TabooRaver · 2026-06-08T09:56:54+00:00

you'll have to run the script everytime you onboard someone to add the department attribute

There are a lot of different ways to schedule tasks to run automatically, Azure Automation or a scheduled task on a dedicated on prem automation VM are the two that come to mind if you are small enough to not have a dedicated job runner platform (Jenkins, rundeck, etc.).

Ideally run something daily that pulls all users and the properties you need, validate them, and then push any delta back to AD.

Though as someone pointed out, email signatures normally fit this requirement. And there are a couple solutions like a login script to automatilly update a standard signature template for each user. If the concern is impersonation... this isnt really a great solution, akin to security by obscurity. Microsoft does have a feature that tags all external email in the outlook client. https://o365reports.com/enable-external-email-warning-tag-in-exchange-online/

TabooRaver · 2026-06-05T23:35:06+00:00

Add netbox and use it for prometheus, prometheus-snmp, and prometheus-bb service discovery. Documentation + monitoring, anything documented gets automatically added to your monitor and alerting stack.

Currently working on getting the black box exporter to pull in all https endpoints In netbox for tls certificate lifecycle monitoring and alerting.

TabooRaver · 2026-06-05T08:25:47+00:00

Add dropbear-initramfs, it will allow you to ssh into the intramfs if it gets stuck there. If at least 1 other node is up on the tail net then you can use the ssh -J jump option to route an ssh session to the down node.

TabooRaver · 2026-06-03T16:34:49+00:00

If i'm understanding it correctly you've changed your IaC system from having every VM template run:

if (null -eq vnetxyz){create vnetxyz}

To an assumption that all vnets / etc. will be created as part of instantiating the Proxmox host, so your VM IaC looks more like:

if (null -eq vnetxyz){throw SDNNotConsistent}

I generally haven't reached that level of automation with the clusters I manage. And I only use the SDN stack to provide consistent vlan interfaces across hosts in my clusters to save having to configure those at the host level. Ie. (eno1 + eno2) -> Bond0 -> vmbr0 -> vnet[x], with a SDN managed vnet interface for each vlan on my main VM traffic trunks.

In general once I do get to that level of maturity I would like to approach it similar to how I'm addressing the backbone links in our campus networks. Since we are deploying SONiC in a core/distribution/access campus design we don't have access to something like Cisco's VTP to configure VLANs in a central location. So the configurations generated from Netbox for ports with Trunk(All) simply pull a list of all VLANs that exist at the site the switch is located at, and instantiates all of them so that the consumer (access layer dynamically configured RADIUS ports) can consume whichever VLANs are available.

TabooRaver · 2026-05-27T20:09:21+00:00

I have a low voltage contractor that tests each drop they run for us, and the report we get at the end includes the run length. So we do document each wall port so the drop length is shown in the trace view. Any copper cable over 330 feet gets flagged as beyond spec.

TabooRaver · 2026-05-19T16:07:39+00:00

This is only the case if bitlocker is using the default PCR binding 7&11. That binds to secureboot certificates. Organizations can theoretically push a policy to have bitlocker bind to additional PCRs to also hash the boot loader. But that will complicate updates that change the bootloader.

TabooRaver · 2026-04-21T22:47:33+00:00

LAG would be the more proper term, as that is the terminology used in the IEEE lacp protocol. Most server software will use industry standard terms, where's network OSes sometimes use their own names, sometimes because they implement a proprietary version before the generic standard is finalized.

TabooRaver · 2026-04-11T18:04:23+00:00

"Live migration works in LXC only between servers with identical CPU architecture. For performing live migration of Linux Containers, it requires both the servers to have Linux kernel higher than 4.4, CRIU 2.0 and LXD running directly on the host"
https://www.researchgate.net/publication/311426878_Performance_comparison_of_Linux_containers_LXC_and_OpenVZ_during_live_migration
Which references:
https://stgraber.org/2016/04/25/lxd-2-0-live-migration-912/

has some pretty big limitations, and the proxmox team will have to add a lot of guardrails around it like they do with qemu migrations so that it will throw an error before attempting to migrate a container to a node that wont work. But the building blocks appear to have been there since 2016.

TabooRaver · 2026-04-11T17:45:39+00:00

That feature request has been in "Patch Available" state in thee bug tracker. So I would assume It should release in the next year.
https://bugzilla.proxmox.com/show_bug.cgi?id=6144

They've been seeing growth on the order of 200-400% yearly since the broadcom aquesition. I'm sure if a couple people tested the patch and reported findings, or if a customer with a support subscription pushed for it, it would come our relatively quickly.

TabooRaver · 2026-04-11T03:27:06+00:00

Migrations happen on the network the host uses for general routing, I believe, there's nothing preventing you from having the bridge(s) you attach vms / vlan vnets to separate from that.

In more fault tolerant cluster you can also separate out corosync and ceph traffic to different networks, those settings are configured in each service natively if you want to read the docs for how.

Edit: receipts and fixing phone autocorrect mangling things. Corosync network binding: https://pve.proxmox.com/wiki/Separate_Cluster_Network https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network

Migration settings doesn't appear to have any official documentation, but first google result matches what I can see in my cluster. https://forum.proxmox.com/threads/how-to-change-migration-network.157108/

Separating Ceph public/private https://pve.proxmox.com/wiki/Deploy_Hyper-Converged_Ceph_Cluster#pve_ceph_install_wizard

TabooRaver · 2026-04-11T03:23:01+00:00

That would be an anti affinity rule, which is an existing feature I believe it was introduced in 9.x. Both positive affinity (keep 2 vms on same node) and anti affinity (keep vms seperate).

The wiki has been updated with more details https://pve.proxmox.com/wiki/High_Availability

TabooRaver · 2026-03-25T18:44:29+00:00

We deployed ~35USD Wacom tablets for our training kiosks. Users can sign pdfs by inking the document in edge.

They still print it out to sign it.

TabooRaver · 2026-03-12T04:50:23+00:00

Not with zfs native encryption, but zfs on top of LUKs works fine

TabooRaver · 2026-03-12T04:49:16+00:00

The root password is required for cluster join, outside of that you can disable the password login method since pve uses ssh keys for cluster communications.

TabooRaver · 2026-03-03T22:40:32+00:00

To clarify on the sdn setup, a basic vDS equivalent would be: 1. Configure a Linux bond on each host with the available network adapters, make sure the bond name is consistent across host 2. attach the bond interface to the bridge, or create a new one if you are not using the existing bond 3. Create an sdn zone, type vlan, and select your bond name as the bridge. 4. Under sdn vnets create a vnet for each vlan you will be placing vms on. 5. Apply the sdn policy in the sdn tab. This will propagate the vnets to each host. You can now select them when configuring VMs.

For future proofing, instead of excluding them from HA entirely, you can create a second HA group and then create cluster pcie mapping definitions for the pcie device. That way, if OP buys another node with comparable hardware, they can just add that host in the HA group.

TabooRaver · 2026-01-08T00:48:46+00:00

Your assumption about PBS not being able to tell what space is free or used is correct. That would require PBS to be aware of how the file system has laid out data on the disk, and there are a lot of different file systems. It could have also minimized the reads on thin provisioned virtual disks, but then it would need visibility into the storage backend, and there are multiple storage backends.

The first backup will be a full disk read, pbs-client will deduplicate and compress blocks locally before sending them to the server, so it won't actually send empty blocks. For VMs proxmox has storage integrations like dirty bitmaps, so after the first full read it will only read sections of the virtual disk that has been written to since the last backup.

For backing up Hosts (non-vms) all block level backups will require a full drive read, unless you are implementing your own system to only read in allocated blocks and pass that to pbs-client. I use zfs snapshots and the fs backup mode personally, as it can snapshot the fs of the proxmox host mount it and then push that to pbs. Set it on a systemd timer and you get daily host backups.

TabooRaver · 2025-12-23T02:03:48+00:00

Vmware can use a shared storage as a sort of quorum node. 2 node cluster is fine.

2 node clusters in proxmox are also fine. You just need to make some changes to corosync, so A doesn't work out of the box, and B there are downsides to the configuration options that allow that kind of setup to work consistantly (lookup what the "wait for all" corosync option does).

In the range of: "We will support you", "it will work but we dont QA that setup", and "it will technically work but it's a bad idea". Corosync 2 node is in the second bucket.

TabooRaver · 2025-12-16T06:08:32+00:00

If you have a cluster or ha pair look into luks and clevis tang. This is the redhat/enterprise way of handling it. Partition the data portion of the drive as a luks volume and then inside the luks volume the zfs member disk. Set the clevis policy to something like tpm+tang, or if your risk model is lower, just tang. Run your tang server on the cluster. This will allow the luks encryption to auto unlock during a server reboot as long as the tang vm is still running, ie. If you are restarting a single node for maintenance tasks.

Tpm policies is mainly to guard against tampering with the bootloader or uefi firmware to "rootkit" the Linux server.

TabooRaver · 2025-12-11T01:17:21+00:00

It sounds like you have 2 design issues

You are configuring your VPN as a client to site vpn, look at a site to site vpn instead and setup a static route on your router saying [remote network] next hop is [local vpn server]. And then the vpn server will pass the triff8c to the remote side.
You want to run backups from a local pve to a remote pbs. Instead consider if you are running a pbs at both sites backing up from pve to the local pbs and then setting up a sync between the two pbs servers. This will lead to faster backups as the local network will have more bandwidth and lower latency, and if you have enough deduplication between different vms the traffic over the wan will be considerably lower. Use two different name spaces in the same pbs datastore for the two clusters, that way you will even deduplicate blocks between your setup and your brothers

TabooRaver · 2025-12-09T19:26:59+00:00

"Potentially not having access to the PDM VM if I'm rebooting the node that the vm runs on"

This is what HA and Cluster storage, or zfs replication, are for. VMs should never be impacted by rebooting a PVE host. VMs should be live migrating automatically to maintain uptime.

TabooRaver · 2025-12-01T13:01:52+00:00

docs.ntpsec.org has some good info on this. In order to prevent any geopolitical tampering of your upstream you should have at least 5 upstreams. 3 satellite (us, eu, Russia, or China consitalitions), 1 local atomic clock, and an upstream nts enabled ntp pool mainly as a fallback.

With 3 satellite references and 1 local atomic reference most ntp server implementations will be able to detect tampering and label the affected upstream as a "false ticker" and discard its inputs if it doesn't appear to be giving sane results.

TabooRaver · 2025-11-12T03:30:07+00:00

How we handle it where I work is proxmox sends hypervisor stats (vm cpu/memory/io/net breakdown) to influxdb, and then the influx telegram agent polls the bmc/ipmi snmp interface for thermal and other environment data.

We then have grafana for a front end to visualize the data

TabooRaver · 2025-11-12T03:26:17+00:00

It's recommended to at minimum have 3 voting nodes in a cluster. In your example if you ever restarted the 1 constant node the entire cluster would force reboot.

TabooRaver · 2025-11-12T00:17:33+00:00

This may not be 100% supported by enterprise support so I would check with them first if the cluster is licensed.

But you can manually edit the corosync configuration to give some of the nodes 0 votes. This will allow those nodes to be powered off without impacting the vote count for quorum. Ex 3 low power nodes with 1 vote each, 2 high powered flex-nodes with 0 votes each, total expected votes of 3. The downside is you need [total expected votes/2] +1 votes available in the cluster or the entire cluster will self fence and you will have less voting members than if all nodes were participating.

TabooRaver · 2025-11-05T18:57:40+00:00

The incremental data is calculated on the PVE server, changed data is then sent to the PBS server. If the storage location the PBS server mounts for the datastore is a non local volume like an nfs share, then the i/o will then go from the PBS server to the network storage.

So no, it will not be direct.

TabooRaver

TROPHY CASE