Mmm, I tried that. It only allows you to select from existing events which probably fuels the rants of the other user ;-)

Wasn’t GOS working with other company to have a second brand that could use GOS? These dudes are nkt stupid and i think they too realuse that relying only on pixels is risky business. I read somewhere that, its not about GOS, the phone or whatever but its about what you need to have so that you can call it a secure phone. The GOS folks have done their homework and concluded that only pixels have what is needed. Whay intreagues me is that the biggest surveilance machine out there built the most secure hardware. Why did they do it?

Totally agree. Its a bit counterintuitive. I suspect its because people share events and locations

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

Its in our language. People dont say “let me search on the Internet” they say “let me google it”. Its going to take a while to move away from that

I think the most notable feature of ddg ai is that its not invasive, and as someone else has said here it can actually be useful. AI is like everything, you need to decide when it can actually add value. If i’m searching for some linux command, ai is brilliant. If i’m doing reasearch i may use ai asking for all references and then i go and check the references using search feature. Sometimes i just use search.