Hello Engineers, I'm currently testing a self-hosted file-sharing solution, Syncthing. Below is a list of options that help achieve a reasonably secure configuration. I haven't described these options in detail, all of them can be found in the documentation. Settings -> General -> Device name -> Fill in the device name Settings -> General -> Anonymous Usage Reporting -> Disable Settings -> GUI -> Start Browser -> Disable Advanced -> GUI -> Address -> Fill in the local network interface ip address Advanced -> GUI -> Enabled -> Leave Enabled Advanced -> GUI -> Password -> Fill in (password to log in to the GUI) Advanced -> GUI -> Use TLS -> Enable Advanced -> GUI -> User -> Fill in a user name (user to log in to the GUI) Advanced -> Options -> Always Local Nets -> Fill in a local network interface Advanced -> Options -> Announce LAN Address -> Disable Advanced -> Options -> Crash reporting Enabled -> Disable Advanced -> Options -> Global Announce Enabled -> Disable Advanced -> Options -> Nat Enabled -> Disable Advanced -> Options -> Relays Enabled -> Disable Advanced -> Options -> Local Announce enabled -> Enabled by default, should be enabled only if local address explicitly specified by the option "Always Local Nets" Advanced -> Options -> Overwrite Remote Device Names On -> Enable Advanced -> Options -> Listen Address -> Left default

When I spin up a new Ubuntu VM on Proxmox, I like to keep the setup minimal but fully functional. My goal is always the same: get proper integration with Proxmox and enable quick remote access via RDP. Here’s the exact workflow I use. Initial Setup After Installation After installing Ubuntu, I skip all optional extras: - Ubuntu Pro → I choose “Skip for now” - Help Improve Ubuntu → I select “No” Once I land on the desktop, I immediately update everything: - sudo apt update - sudo apt upgrade -y Installing QEMU Guest Agent One of the first things I install is the QEMU Guest Agent. It makes Proxmox much more aware of what’s happening inside the VM. - sudo apt install qemu-guest-agent -y After that, I shut the VM down: - sudo poweroff Then on the Proxmox side: - I remove the installation ISO (Hardware → CD/DVD → Remove) - I enable the QEMU Guest Agent (Options → QEMU Guest Agent → Enable) When I boot the VM again, I quickly check if it worked by looking at the Summary tab, if I see the IP address there, I know everything is working correctly. Setting Up XRDP For remote access, I usually go with XRDP since it’s simple and works well enough for most use cases. First, I install it: - sudo apt install xrdp -y Then I fix a small but common permission issue: - sudo adduser xrdp ssl-cert Next, I tweak the XRDP startup script: - sudo nano /etc/xrdp/startwm.sh At the top of the file, I add: - export DESKTOP_SESSION=ubuntu - export GNOME_SHELL_SESSION_MODE=ubuntu - export XDG_CURRENT_DESKTOP=ubuntu:GNOME After saving the file, I restart the service: - sudo systemctl restart xrdp Connecting to the VM At this point, I just grab the IP address from the Proxmox Summary tab and connect using any RDP client (Remmina). I log in with the same user I created during installation, and that’s it, I have a working GNOME desktop over RDP. Optional Notes If I happen to be using UFW, I also open the RDP port:

This may be super easy for everyone in here but it was a big accomplishment for me today. I have my own email linked to my personal domain. I wanted to be able to respond to customers using the gmail app on my phone. The problem was that all of my other emails (support@lop.com for example) were not properly sending emails. They were able to receive, but if i replied it went into a "queued" status. The fix was to reenter all of my smtp info and resync with the gmail app. Everything is working great now. I love being able to fix a technical challenge that i have no background info for.

I’m currently testing different configurations for virtual machines in my Proxmox setup, and it reminded me of a story I once came across. I’m not sure if this story is entirely true, but it’s still worth telling. A few years ago, someone on a small DevOps forum shared a painful story. He had a “temporary” Ubuntu VM running on his home server—nothing public, just a test box behind NAT. He skipped hardening because “it’s not exposed anyway.” A few weeks later, one misconfigured port forward and a weak SSH setup were all it took. The machine got brute-forced overnight, quietly joined a botnet, and started sending spam. He only noticed when his ISP throttled his connection. That story stuck with me. Since then, I always do a minimal hardening routine—even for throwaway machines. Here’s what that looks like. 1. Create a non-root user First thing: stop using root. adduser myuserusermod -aG sudo myuser 2. Set up SSH keys On your local machine: ssh-keygen Copy the public key: ssh-copy-id myuser@server_ip Or manually place it in: ~/.ssh/authorized_keys Make sure permissions are correct: chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keys 3. Log in as the new user Reconnect: ssh myuser@server_ip Update the system: sudo apt update && sudo apt upgrade -y 4. Disable root SSH login Edit: sudo nano /etc/ssh/sshd_config Set: PermitRootLogin no Restart SSH: sudo systemctl restart ssh 5. Set hostname properly Edit: sudo nano /etc/hostname Use a fully qualified domain name if possible, for example: server.example.com Then update hosts: sudo nano /etc/hosts Modify: 127.0.1.1 server.example.com server 6. Reboot sudo reboot 7. Configure firewall (UFW) Install and enable: sudo apt install ufwsudo ufw allow OpenSSHsudo ufw enable 8. Install Fail2Ban sudo apt install fail2ban Default config already protects SSH reasonably well. 9. Change SSH port Edit: sudo nano /etc/ssh/sshd_config Change: Port 2222 Update firewall: sudo ufw allow 2222/tcpsudo ufw delete allow OpenSSH

Currently I am working as senior software engineer and founder, I am looking for a partner based in Netherlands. For expanding my development business and cooperation with partner, I have clear idea. Programming skills are preferred but not mandatory. Let's talk in dm in more details.