Introduction:

Since I was first introduced to virtualization, ESXi has been my go-to solution. Its reliability, performance, and robust feature set made it an indispensable tool in my arsenal. But as time passed and the landscape evolved, my loyalty to ESXi began to waver.

The Broadcom Factor:

One of the key catalysts for my departure from ESXi is the influence of Broadcom. Their acquisition of VMware's vSphere assets brought about changes that I, along with many others, found concerning. The shift in focus and direction left me questioning the future of ESXi and whether it still aligned with my needs and values.

The Exodus to Proxmox:

As I grappled with these uncertainties, a significant trend emerged among my clients – a mass migration to Proxmox. Intrigued by their enthusiasm and eager to explore alternatives, I embarked on a journey to familiarize myself with Proxmox. What I discovered was nothing short of revolutionary.

Embracing Proxmox:

It didn't take long for me to realize that Proxmox offered everything I loved about ESXi and more. Its open-source nature, comprehensive feature set, and vibrant community support were exactly what I had been searching for. With each passing day, my confidence in Proxmox grew, and it became increasingly clear that this was the platform I wanted to build my future on.

A Paradigm Shift:

Today, as you read this blog post, know that it's being served from my Proxmox server – a symbolic representation of the paradigm shift that has taken place. It's a testament to the journey I've embarked on and the exciting possibilities that lie ahead. Goodbye ESXi, and hello Proxmox.

Conclusion:

While bidding farewell to ESXi was not an easy decision, it was a necessary one. As technology continues to evolve, so must we. And in Proxmox, I've found a partner that not only meets my current needs but anticipates and embraces the future. So here's to new beginnings, to embracing change, and to the endless possibilities that await. Goodbye ESXi, and hello Proxmox – I'm excited for what's to come.

I discovered Cloudflare tunnels and quickly ported all my applications over to/through their platform. It is truly amazing. In this process i changed some URLs and are now reaping the delayed errors of such a change.

I am using the manual integration here:

Google Assistant

Setup for Google Assistant integration

Home AssistantHome Assistant

The Google Assistant integration failed, of course. Google Actions are trying to connect to https://old_url instead of https://new_url. The problem is that new_url required authentication from/through Cloudflare. That's not straight forward and needs to be bypassed. First i bypassed /api path. That didn't help. I re-read the documentation and surely found /auth which was also bypassed. That didn't help either so I started writing this blog post instead. I am now going to further read the documentation and hopefully discover something else...

I re-read the documentation whilst restarting home assistant. I could not find any other possible changes to be done so i tried again; "Hey Google, synchronize my devices" her reply was magic and strangely in my native language which i will translate for readability

Ok, synchronize the devices from Home Assistant, Sensibo and Sonos.

There you have it. The fix above worked and all i had to do was update the URL in three places according to the linked integration documentation.

I had to change the "Fulfillment URL" on the "Develop" tab, subsection "Actions". Then under subsection "Account linking" i had to change both auth URL and Token URL. Save everything very much. Patience, then reboot Home Assistant.

Jeg har ganske nylig fått en oppvekker for hvor digg backup kan være. Jeg flyttet alle systemet til en ny server, i den forbindelse gjorde jeg alle innstillinger manuelt på ny. Det er strengt tatt ikke alltid nødvendig, men en gang i blandt kan det være nyttig for lærdom og virkelig se hva som skjer under panseret.

Det gikk nesten galt

Mye av problemet var at jeg ikke eksportert mappene med innstillinger i diverse docker konteinere.. dermed gikk de tapt sammen med en merkelig docker oppførsel. Det er uansett spilt melk og må kun glemmes. Alt er omtrent 95% oppe og går igjen så puttsann heisann. Nå er det backup som gjelder.

Jeg har satt Active Backup for Business til å ta backup av system imaget en stasjonær PC hver natt i forkant av offsite backup timeplanen. Det er greit nok det, men alt det gir meg et en notat i loggen og en sikkertskopi en plass.

Hva om PC-en krasjer?

Hva hvis driten treffer vifta og jeg må gjenopprette? Hva som skjerm ble svart i det jeg skriver dette og alt blir borte? Hvordan får jeg PC-en opp igjen? Synology har følgende påstand:

Entire device restore: Entire device restore is available with a recovery media. To restore the entire device or the backed-up volume, please create a recovery media in advance. You can refer this creation guide to learn how to use Synology Active Backup for Business Recovery Media Creator to create a media automatically or create a customized media. You can download Synology Active Backup for Business Recovery Media Creator in Download Center. For more information on restoring the entire device, please refer to this article.

Én av linkene linker til en .pdf som igjen linker til programvare som vi finner her

https://global.download.synology.com/download/Tools/ActiveBackupRecoveryMediaCreator/2.1.0-0436/Windows/Synology%20Restore%20Media%20Creator-2.1.0-0436.zip

Litt dobbelklikking, høyreklikking og dobbelklikking så fikk vi start på programvaren:

Siden det var første gang den kjørte så tok det ekstra lang tid, men vi fikk opprettet en USB disk til slutt

Vi gjør klar merkelapp og booter opp den nye USB disken vår:

Her kommer det en link til del 1 om jeg noen gang fullfører dette.

Jeg herjer mye med zip filer for tiden. Det er mye som må zippes opp, manipuleres og zippes igjen. Jeg har flere ganger holdt på å rare filene i stede, det går ikke bra, det må være zip. Etter å ha irritert meg fire-fem ganger over at zip ikke er et valg i innholdesmenyen tok jeg endelig affære.

Jeg forsket litt i menyen og fant følgende innstillinger

Det var alt

Etter en uke med cache som ble installert i innlegget under har jeg gode nyheter

Read write cache

Hva er vel lagring uten mellomlagring? La oss oppgradere fra read-only til read-write cache i DSM

TROLOGTrond Sundt

Cache hit raten er 82% som bidrar til økt hastighet og besparelse av snurrdiskene. Hurra hurra :)

Som alle andre normale folk så kjører jeg kun  PPTP og L2TP VPN hjem og har egentlig vært fornøyd med det. I senere tid har jeg gjestet andre aktørers gjestewifi og opplevd at VPN kommunikasjon er blokkert og har i den forbindelse testet diverse kommersielle VPN løsninger uten å bli særlig fornøyd.

Ved første anledning installerte jeg OpenVPN og la egentlig ballen død. Noen dager senere ble jeg kontaktet på SoMe med følgende informasjon:

Såeh. Det sier seg selv at jeg må prøve Wireguard. Jeg forsøkte først å sette WireGuard opp via docker men det ble mye blabla kernel og blabla config så fuck det. Jeg tenker en VM på XPE datastoren får være godt nok. 120s delay autostart.

For å komme i gang trenger vi en VM:

Vi velger en datastore i neste vindu og beholder alle standard innstillinger

Som OS velger vi ubuntu-20.04.1-live-server-amd64.iso

Etter installeringen må vi restarte

Til selve installeringen så har heldigvis angristan på github lagt et bash script :)

angristan/wireguard-install

WireGuard VPN installer for Linux servers. Contribute to angristan/wireguard-install development by creating an account on GitHub.

GitHubangristan

Om du er så uheldig at angristan har fjernet scriptet sitt så tok jeg en kopi 20.09.2020 som du finner her:

angristan/wireguard-install

Kopi av angristan sitt wireguard script fra github

TROLOGTrond Sundt

Når maskinen har restartet så legger jeg den inn i autostartlisten på ESXi. Jeg reseverer en statisk IP adresse i DHCP. For å slippe å jobbe via VMWARE console så remoter vi inn med putty heller. Det første vi gjør er å kjøre sudo apt-get update && sudo apt-get upgrade

Som en godbit til meg selv kjører jeg også sudo apt install net-tools og rebooter av gammel vane

sudo reboot

Nå er vi klar til angristan sitt script. Vi kjører sudo curl -O https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh && sudo chmod +x wireguard-install.sh && sudo ./wireguard-install.sh

Under installeringen må du oppgi ekstern IP adresse samt to DNS tjenere:

Installasjonen avslører server port på 49850 UDP som vi åpner i brannmuren.

Badaboom. Wireguard er installert :) Have fun