This will never happen. Most good channel on YT are content creators that make a living on their content. PeerTube will always be a grain of sand on the beach. Sadly …

Totally agree. The simple fact tgat every bank or setvice provider forces me to use their app for 2FA is really annoying as it forces me to need several apps for the same job

I’ve been wanting to get more into this nitrokey business but haven’t done my research. Are you using it for all your day to day authentication? Can it be used for websites? Logging onto laptops, etc?

ran the above and the following pops up. the MAC ending is c3 is the new one I assigned to the 20.91 address on DHCP pfsense server about an hr ago.

EDIT: wondering whether this may be a network manager problem on the VM client? See here

EDIT2: Even tried running ip addr flush dev <your_adapter_id> as suggested here but no effect at all

EDIT3: This is now solved. It was a client problem. Somewhere buried in the system, a static IP had been set up on this machine in the past I image.

When running ntmui, the 106 address was configured as static address. Deleted it and now only sees the 91 address. Didn’t realise you coudl set two IPs against same interface. This is the page that helped following advice from @[email protected] of runnign dhclient -v ens18; for i in $(seq 60); do ip a s dev ens18; sleep 1; done

deleted by creator

a) turned off VM b) deleted the static mapping and recreated c) change the MAC on the VM and then the same MAC on pfSense d) checked /var/dhcpd/var/db/dhcpd.leases and there is no sign of any 192.168.20.XX lower than 20.110 (from 110 I leave the space availble for occasional wifi access of devices not in my home) e) Rebooted pfSense

absolutely the same problem again :-(

don’t I have not configure proxy arp on PVE. the only arp is what I see cached by pfSense. tried flushing the table in pfSense with not luck … the VM is still hooking up to 106 and this is confirmed in the pfSense ARP table even after flushing, despite the DHCP lease table saying that the VM is hooked to 91.

Can I just check with @[email protected] and @[email protected] that what I’m doing is what you are saying.

I’m not setting static IPs at client level. Would be a nightmare. What I do is assign IPs on the DHCP server i.e MAC address on VM1 is XX:XX:XX:XX so I set this MAC address in DHCP to correspond to IP 192.168.20:XX so that the machine gets a unique IP all the time. Is this what you meant? I thought everyone would be doing this nowadays as it so easy to manage, except when something goes wrong like in this case.

Maybe I’m misunderstanding but what I mean is that I assign static IP via DHCP based on the MAC. I’m not setting static IPs at client level. i.e MAC address on VM1 is XX:XX:XX:XX so I set this MAC address in DHCP to correspond to IP 192.168.20:XX so that the machine gets a unique IP all the time. Is this what you meant?

No netplan folder under either /etc/ or /var/run/

See message above. I doubt it. I would have had this problem a lot earlier with other machines.

What a surprise … if I were to believe this I would file for madness state support. Look like the VM is having a nice chat with the DHCP sever and both agree that the IP should be 192.168.2’.91. Then one of the two cheat, and actually work on 106. Logs in DHCP server a showing nothing. I even told pfSense to ignore the machine ID and it had no effect whatsoever. If there was another DHCP server hiding somewhere, dhclient would have picked that up presumably.

Just to be clear, this is what is in the ARP table on pfSense: and this is what is in the DHCP lease table in pfSense. What I’ve concluded is that the DHCP sees the VM is online, it probably offered the 91 IP, and just shows it online. The ARP table is showing what the actual assigned IP is (106) and SSH login attempts confirm this. There is no 106 entry in the DHCP table. I would ignore the VM2 element of the equation i described above for now. I added just to describe the conflict that arose when I switched it on. I woudl also say that VM1 was backed up on another Proxmox server I had runnina and then restore it on this new Proxmox server I have with a bigger NVMe.

But if there was another DHCP server hiding somewhere, i would have had this problem years ago with all the other machines that are using the same router/DHCP server?

Well, because its all managed in one place rather than having to go and configure loads of machines

I hadn’t realised that matter was making such progress. I was about to start installing KNEX stuff at my home, which I would later integrate with Zigbee or the other stuff.

You need to share your setup then … :-) I wanted to set this up next.

I’ve been using OpenHab2 for several years now but it only collects data from a few esp sensors I built during covid. I need to get it updated and use it more seriously

So I created an ext4 256GB partition at install time hoping when logged in the GUI, I would get the option to create a ZFS partition on the free space of the NVMe. However. the free space is not showing up under disk and I don’t get the option to add another partition, whether ZFS or other. Any clues why this would be?

Ok, but I assume this means that I have to configure the new node from scratch, adding the storage, etc. Correct? So the steps would be:

a) build new node with spare Optiplex + 1 new NVMe and install Proxmox from scratch b) configure the new node and add to the cluster c) migrate the VM from old now to new node d) decomission old node but installing the 2nd NVMe and Proxmox from scratch e) add the second rebuilt node to the cluster again.

Did I get this right?