via GIPHY

First thing that came to mind seeing this ; WHY??

Why would you want to run a VM from a Samba-share. One could argue that having TrueNAS ZFS for replication and snapshot could be valuable, and since it's all running on a virtual network you would not be encumbered by the speeds of your physical network-adapter. Proxmox has support for ZFS out of the box and though Proxmox itself is not really a solid solution as NAS, using ZFS with a bunch of SSD's in mirror for VM's would probably be a lot faster than running those VM's from a SMB-share.. Or NFS for that matter.

But then again; most of the guys in those video's were very positive about VM's on SMB-shares so I had to check.

via GIPHY

The setup

I installed TrueNAS Core in a VM running on a NVME SSD. I gave it 4 cores and 24 Gb's of RAM and 2 virtual NIC's. Both paravirtualized VirtIO nics, this is important because this allows speeds up to 10Gbit/s. If you use Realtek or Intel you're essentially emulating hardware with lower speeds (up to 1 gbit/s).

My TrueNAS VM has 2x3,5" Harddisks in mirror and one 2.5" SSD (Samsung) as striped ZFS dataset. All disks are connected to SATA-ports. I added these disks following this guide. Both ZFS datasets have no caching disks at all.

For testing I've created a clean Debian 11 VM with Gnome desktop. The VM itself runs on the same NVME SSD as TrueNAS Scale runs from. Debian has 2 cores, 2Gb RAM, one VirtIO Paravirtualized NIC.

Benchmarking

I wanted to run several test-cases;

• HDD vs. SSD
• SMB vs NFS
• Virtio SCSI vs Virtio Block (and SATA)
• Raw vs qcow2

These are settings from Proxmox, everytime I wanted to benchmark a new test-case I created a new virtual drive and assigned it to the Debian VM. SMB and NFS shares are mounted from Proxmox.

For benchmarking I used the default disk-management app from Gnome. There's a benchmark feature and every time I used 100 samples of 100MiB each. I also ran some real-world tests by copying a large file from local to the mounted test-drive.

Observations

I did test most scenario's with SMB as well. While benchmarking with the Gnome Disk-tool went fine I could not do any real-world tests; the VM would freeze after 10 seconds of copying and Proxmox would throw a IO-error. I have encountered this before while trying to install a VM on a SMB-share. So I left these results out of the conclusion.

Another observation; when using qcow2 as format I could run the benchmark once, the second time the transferspeeds would exceed 20gbit/s. I'm not sure why this happens and this needs further investigation.

The results

One day, when I finally understand Excel I'll generate some nice graph's. But for now I'll stick to raw data and a conclusion.

To view the raw results, check out this Notion database

Conclusion

Best performing setup is a ZFS dataset backed by a SSD, shared over NFS, connected to a VM using VirtIO Block and file-type RAW. Real-world writes are around 280mb/s and reads around 560Mb/s. Not at all bad, especially if you compare those number with a virtual disk running on the NVME-ssd (360 mb/s write, 420mb/s read). What really surprised me is the fact that reads are slower from NVME, maybe because the SSD is also running the TrueNAS and Debian VM's? The SSD from TrueNAS is only a SATA disk and it has some overhead from NFS as well. So I do not really understand why NVME is performing significantly worse in this scenario.

If you don't have a ZFS dataset backed by SSD you will get decent read-performance from a HDD backed ZFS dataset, around 560 mb/s, but writing to that set is pretty slow; around 80mb/s.

There are some things to keep in mind.

via GIPHY

If you are running a lot of VM's, and some of those VM's are accessing data from TrueNAS using NFS you will suffer from lower throughput. The VirtIO NIC performance will be hindered by the CPU and is the bottleneck in your system. I did not test the disk-throughput when NFS is handling other stuff as well (maybe another day).

Final thoughts

Though performance is really good when running from a shared ZFS dataset it still feels wrong to me. Especially if VM's will be accessing files from the same ZFS dataset over NFS. I did not even touch on access times and those are a lot worse on shares. Random access and databases running in a VM on a share would probably perform pretty bad. I'll be benchmarking the same setup only with TrueNAS core instead of Scale, I don't expect huge differences but it would help making a decision about where to store my ZFS dataset.

In the end I will be running my VM's from 2 SSD's in Mirror in ZFS on Proxmox, not using shares.

via GIPHY

via GIPHY

In my current setup TrueNAS Core shares datasets with FreeBSD-jails (running apps like Plex, Sonar, IceCast) using null-mounts. You mount a dataset from the host into the jail and you're done. No hassle with NFS, SMB, iSCSI, just simple null-mounts. You can make them readonly which is nice, you generally have less issues with access-rights and most important of all; it's FAST. You're accessing the dataset directly and not using any layers in between.

I did run 2 VM's with BHyve on TrueNAS core, this is slow to begin with, and you can't use null-mounts, so accessing data from the host in a timely fashion is quite a struggle. Those who remember the days of FreeNAS (especially 9.x) know the pain with PHP-virtualbox, so BHyve looked like a blessing at the time ;)

I've come up with several scenario's which I'm currently investigating.

via GIPHY

1. Proxmox Host, TrueNAS Core VM

Effectively moving my current server to a VM

I'll be installing TrueNAS Core 13 as VM running on Proxmox. All 3.5" disks (storage) will be mapped to the VM and TrueNAS will expose the datasets using NFS, AFP, SMB or iSCSI. There's one very big advantage to this setup: I'm able to transfer all my drives from my old server to the new one (even the SSD's running the jails) and restore the configuration from the old server in this new VM. All services will be up & running in no-time and to a certain degree I have the power-efficiency I was looking for. In time I'll be moving the jails in TrueNAS to VM's in Proxmox.

Another advantage; I'll keep using FreeBSD under the hood, albeit virtualized. I like FreeBSD.

The downside; I have 6 SATA ports on the motherboard available and I will need all of them to run the 4+2 disks from my old setup. So there's no room for an extra set of SSD's to run new VM's. I can solve this by adding a PCI-SATA controller (which I still have laying around) however; this will increase power-usage.

Another downside; FreeBSD (on which TrueNAS core runs) is not known as being a very power-efficient OS, so eventually I will need to replace TrueNAS Core with something else when I'm done moving all the jails to VM's.

2. Proxmox with TrueNAS Scale VM

I'll be installing TrueNAS Scale as VM running on Proxmox. My current dataset can be easily imported. I will have to rebuild all jails in VM's in Proxmox, datasets will be shared using NFS or SMB (no AFP support in Scale unfortunately).

I can use plugins (K8s) in Scale to run services, this would make it a bit easier to migrate all my stuff. I can even create VM's in a TrueNAS VM with KVM! I tried that and performance ain't that bad, not nearly as fast as a VM on Proxmox though. True VM-Inception!

But then again; TrueNAS Scale has KVM support, maybe not as incredible as Proxmox but good enough for me. Both are Debian Based, both are fairly energy efficient, so the real advantage of virtualizing TrueNAS is not really clear to me. The only thing I came up with; I can manage the TrueNAS VM (rebooting and such) easily from Proxmox.

3. Proxmox with Debian VM (and Docker!)

This solution was brought to my attention from one of the nerds from Met-Nerd-Om-Tafel-Slack. I'll be installing Debian as VM in Proxmox. Let Debian deal with ZFS and share the dataset. Debian will also run docker for services. Other VM's can be run from Proxmox (like PFSense or Home-Assistant) so if the Debian-with-docker instance needs to reboot other services won't be impacted (as long as they don't use the shares from the dataset).

This is a terminal only-solution (you could run a desktop environment from Debian though). I can manage that but since I've been using FreeNAS I did get used to managing my server with a web-interface. One big plus; this is very power-efficient.

4. Just TrueNAS Scale

Not virtualized, just TrueNAS Scale on bare metal. All the advantages from #2, but without overhead from Proxmox (though it's not clear how much this overhead really is). I can run K8s-templates/apps, Docker and Docker-compose, use KVM, have a nice NAS-solution and pretty web-interface.

I have not tried it yet but I did run into some networking issues when I ran TrueNAS on a VM, so those issues need to be ironed out before I'm satisfied with this choice. And i'm not that versed with k8s yet, but the UI from TrueNAS takes a lot of complexity away.

#5 Just TrueNAS Core

This would be by far the most easy way to migrate. Just move the SSD's, HDD's and boot-USB from old server to new one, boot it up and I'm good to go. But there's no fun in that and the power-efficiency of FreeBSD (or lack thereof) would become an issue for me. Oh; and the pretty bad virtualization support.. So, this is no-deal.

General thoughts and unanswered questions

via GIPHY

There are some general issues I've been wondering and thinking about.

1. I only have 32gb's of RAM. Will that be enough when I'm moving to more virtualization?
2. The Fujitsu Board (D3644-B) has 2 M2-slots. One 80mm for SSD's and one 30 mm for Wifi. Can I use the latter M2 port for storage as well?
3. The specs of the Fujitsu board say it supports up to 64Gb's of RAM, but I've seen reports it can also go up to 128Gb. Not sure if this is really the case though.
4. I have a Intel 1gbit dual-nic PCI network card in my current server, should I move that to my new machine (the Fujitsu board has a Intel NIC as well). Could be of use when splitting up my network, but it might use more power.
5. If I'd get a set of new SSD's for storing VM's, which ones would be suited for ZFS in mirror? I've read several posts on the TrueNAS forum about Samsung SSD's which fail after a few weeks due to too much writes. I always assumed Samsung SSD's were on of the best out there.
6. Can I (and should I) forward the Intel GPU to a VM to run hardware encoding for Plex? I've seen video's of people doing that, but I'm uncertain if the onboard GPU can be forwarded to a VM.
7. Does TrueNAS Scale support forwarding USB-devices to VM's? If not I won't be able to migrate Home-Assistant from my Raspberry PI4 to TrueNAS Scale.

I'll be doing some benchmarking and reviewing of each of the possible setups next days/weeks to get better understanding of performance impact and power-efficiency.. I'll reporting back here!

via GIPHY

I've been running a home-server (NAS) for ages. It started back in the early 2000's with a Mac Mini and a bunch of USB-harddisks, connected with a USB-hub. I used it as NAS, recorded tv-shows with it (with an Elgato Coax-tuner), served PHP pages with Apache. Fun times ;) I bought a "real" NAS several years later (not sure but I think it was a QNAP) and kept using the Mac Mini for services.

Around 2010 and a lot of failed USB-disks later I build my first full system; a Tower PC with Core2Duo, 8Gb of RAM and 6x2Tb + 2x500gb HDD's. At first I tried to use Ubuntu with soft-raid until a friend mentions ZFS. I quickly installed PCBSD (FreeBSD with a desktop environment) and created my first ZRAID-dataset (I used ZRAID2 which was a wise choice in hindsight). I installed all services I needed in FreeBSD-jails and all was fine and dandy. This one day I lost 2 drives at once, both were pretty old and I was very happy I chose ZRAID2 for my dataset. After a while I stumbled upon FreeNAS and fell in love with it. I decided to backup all my data and setup my home-server with FreeNAS. Again; fun times!

In 2016 I decided to build a new server with new drives. My focus was on a more energy efficient system, and I needed more storage. So I build a new system with an I3-6100, 16Gb of RAM and 4x3Tb in ZRAID1. I added an SSD as ZIL. I used FreeNAS again.

via GIPHY

This system is still running. Doing a lot of stuff; downloading, VPN Gateway, Reverse Proxy, IceCast streaming, Security Cam Recorder, Plex Media Server, hosting websites, GIT, VSCode Server, Home-automation. Officially the hardware is still good to go, however; the energy efficiency is not that good compared to modern hardware. It's never idle, but doing it's thing it uses about 115watt.. Which is quite a lot.

So; time for a new home-server

Hardware

I spend a good month researching energy efficient parts, from the motherboard, the best CPU to new drives. The forum on the dutch website Tweakers.net has a very long thread about energy efficient hardware and I talked a lot about it with my nerdfriends on Met-Nerd-Om-Tafel-Slack.

via GIPHY

• Intel I3-8100
• Fujitsu D3644-B Motherboard
• 2x Corsair Valueselect DDR4-2400 memory (non-ecc, yeah, I know)
• be quiet! Pure Rock 2 black CPU Cooler
• Corsair RM550x power supply unit
• Cooler Master MasterBox NR600 Midi Tower
• Gigabyte 128Gb PCI-E M2 SSD

I'll be reusing my 4x4Tb WD Reds and I'm planning on buying 2 Sata-SSD's. Eventually I'll add 2x16Gb of RAM to get to 64Gb. I expect the WD Reds to keep up for another 2 years after which they will be replaced by either 2x16Tb or a bunch of 2,5'' disks (which are more energy efficient).

After receiving all parts I went to work and in 2 hours I had my new system up & running. After some small tweaks in the BIOS (mainly enabling P-states) and installing Debian 11 I checked my power-meter; 7 watts idle!! now that's a difference! Ok, the system was running without the powerhungry 3.5" disks, but I'd looked promising already.

Next; determining what OS to use.

Software - Analysis Paralysis Awaits!

Kudos to Saber Karmous for the term Analysis Paralysis

via GIPHY

The list Must-haves

• Mature ZFS support
• Able to run docker containers
• Able to install apps from either templates (jails/k8s) or docker-compose
• Able to map USB-devices to VM's or container (in order to replace my Pi4 with Home-Assistant)
• Able to run VM's
• Assign a LAN-IP to each of the VM's or containers
• Energy-efficient (doh)
• Be extremely quiet
• Reuse my current ZFS dataset without moving data to a temporary set of disks
• Easy to restore in case of emergency
• Have decent throughput
• Run all the stuff I use already (preferably more :p )

The list of wanna-haves

• Able to assign VM's or containers to specific VLAN's (though I still have no idea how I got this working on my current setup)
• Capable of running OBS from a Linux VM and transcode 2 live-streams at once
• Replace my current fiber-router (OPNsense)

The contenders

via GIPHY

There's a lot out there. But this is my shortlist

• TrueNAS Core. Trusty TrueNas. I know my way around this OS, it's incredibly stable and secure. Does most of the things I want it to do, but there is one big downside; it does not run everything I throw at it. I've had several moments past few years in which I simply just could not get something to run on FreeBSD because there was no FreeBSD package for it. Yeah, you can use BHyve to start a VM, but it's quite cumbersome to configure and it's not fast.
• TrueNAS Scale. New kid on the block. Looks very promising. Based on Debian 11, with mature ZFS support, docker/k8s out of the box, virtualization with KVM. Looks like a perfect solution. And it probably is. I've tested it on my laptop in VirtualBox and I was impressed. I have not been able to assign LAN ip's to containers or VM's but I did not spend a lot of time on that yet, I'll probably get that working as well. This one I need to check out.
• Proxmox. Looks promising. I looked at Proxmox years ago, did not like it back then, but I saw a lot of video's about it and I think I should give it another chance. Also to be checked out!
• UnRAID. Has a lot of fans, I'm not one of them. The way UnRAID handles disks seems very efficient and safe, but I want ZFS, I like ZFS, I know ZFS and ZFS saved me several times before. There are plugins for UnRAID to have it support ZFS, but it feels a bit wonky to me. It's on the list, but I'm not sure if I really want to try it.
• Plain old Debian with ZFS. I can install another Debian VM on top of it with docker containers, for easy rebooting. No shiny GUI, just plain ol' terminal. But it seems flexible and possible incredibly fast. Must try this as well.
• Finally; Any combination of one of the solutions mentioned above.

Say what? Yeah, I came across this video on youtube where this guy has a Proxmox-host, installed TrueNAS Scale as a VM, pass along a hardware-controller with a bunch of harddrives to TrueNAS Scale and setup a ZFS dataset in the TrueNAS VM, returning the disks to Proxmox using SMB-shares. Proxmox was now able to run VM's from those SMB-shares. I was watching this and first thing that came to mind; what's wrong with this guy? Proxmox has ZFS support, why would you want to run ZFS from a VM? And why would you want to run VM's from a SMB-share???

I have questions

via GIPHY

I mentioned this TrueNAS as VM in Proxmox in Slack to my nerdfriends. The first reaction I got was; yeah, I have my server running exactly like in that video. Aight, this is a thing?

So, I'll be installing Proxmox, I wanted to take a good look at it anyhow. Time for some benchmarking! In a few days I'll report back here!

Subscribe to be updated when I report my findings!

via GIPHY

What to expect from this guide?

After following these steps, you'll end up with a development server which you can use to work on Node.js frontend and backend projects. You could probably use it for other stacks. From my experience working with this setup is almost the same as running VSCode on your own machine, except it's not on your local machine.

You can connect your local VSCode editor with the VSCode server using SSH. Code completion, 'go to definition', debugging, running your code, even the terminal, it's all the same. If you ever worked from VSCode on Windows with locally running containers or WSL ; it's exactly the same.

Your development server will connect to your Global Area Network using ZeroTier. This makes it easy to connect without the need to change local configuration each time you start the server and it gets a new IP-address. Your development machine will be available from a local network. Nice bonus; you can completely fence the VM behind a firewall and still have SMB access.

Why would you want to run VSCode from a server?

Couple of reasons

• Resources; a fairly complex webapp can contain a lot of files and do a lot of resource hungry stuff. My main development machine is a Macbook Pro 13'' from 2019. It has an Intel Core i7 and 16 GB of RAM. Should be enough, right? While working, most of you have other stuff running; Slack or other chat apps, an email client, your browser (most webdevs have several running at once), a music player. My Macbook does throttle a lot and gets pretty hot when working on a fairly large codebase in TypeScript. Using a dedicated VM will result in faster transpiling, faster response when testing your app, faster code completion and overall a more productive IDE/text editor.
• Security; having the code I write for my employer sitting on a system from my employer is safe. If you're freelancing you can even use this as a USP; "everything I code for you is on systems you own".
• Flexibility; you can work from whatever machine you have within reach, as long as it is connected and has VSCode. Let me correct that; as long as it has a decent browser. You can use a normal local VSCode instance to connect to your VSCode server, I'd recommend this as daily driver. However; since VSCode is a webapp you can also use your browser to connect to your VSCode server. You can use a Chromebook, or even an iPad with a keyboard. You have the full functionality you'd have when you use the VSCode application. And since your code is not actually on the machine you're using it does not really matter if it's a company laptop or personal laptop.

Costs

Free Microsoft credits aside, this VM will probably set you back around $25,- per month. You can shutdown the vm when you are not working, but you will need some grunt to comfortably run VSCode server. I use the Standard B2ms (2 vcpus, 8 GB memory) VM-size which costs $70,- per month. That's steep, and you might get the same results use the B2s instance, which has 2 cores, 4GB of RAM and 16GB SSD and will set you back roughly $15,- per month. If you'd left it running a full month you'd be paying $35,- per month. I'll be testing the B2S instance upcoming week and will report back on my findings.

Update : after one morning working on the B2s instance I ran into memory issues. I had 3 projects open, 2 of them running (a serverless backend and a isomorphic frontend), I noticed the editor getting sluggish and top revealed there was no RAM left. Since by default the Azure Linux VM's have no swap enabled the VM was slowly crashing. So I created a swap-file using the procedure described at the end of this article and I'm currently working with 4GB RAM and 5GB of swap.

Prerequisites

I assume you have all of the next items in place, or know a decent amount about;

• An Azure account, either with credits or a valid creditcard and reasonable understanding of what Azure is, how to use it and the way the webapp works.
• Comfortable with Linux terminal, you know how to create a SSH-key, install packages
• You already have a ZeroTier account and the ZeroTier client installed on your own machine. There are a lot resources explaining setting up ZeroTier, so use the-Google for that (or read this)
• If you want to secure the webinterface with an SSL certificate; a (sub)domain of which you can update the DNS records(recommended!)

Let's get started!

• Create a Virtual Machine in Azure in the region close to where you are, select whatever type you want and what your credit card allows. I will be setting up a B2s instance, with 2 Cores and 4GB or RAM.
• Select Ubuntu Server 21.04 - Gen1 as image.
• Use SSH public key authentication and use the key Azure creates or use a key you already have in place. Please note; you can not use ed25519 keys for now. Don't forget to enter a username to login.
• Network; for now allow SSH (22) and port 80 (service: http).
• Disks; depending on your needs you can add extra data disks. For my situation the standard amount of 32 GB is enough.
• Management; Enable auto shutdown and set a time that's convenient for you, I use 9 pm, the likelihood of me still working at 9 pm is very slim.
• When the VM is up and running, connect to it with SSH. You can use the IP found at "Overview" in the Azure portal. If the SSH key you used is not the default key you can use the -i argument to switch sshkeys like so:

  ssh -i ~/.ssh/id_rsa user@address
  

• First thing I usually do is add my ed25519 key to ~/.ssh/authorized_keys (optional).
• Second thing; update the system;

  sudo apt-get update && sudo apt-get upgrade
  

• Configure max_user_watches. If you keep this at it's default value you might get errors like this Error: ENOSPC: System limit for number of file watchers reached when you use node_modules like nodemon or other file watchers in larger codebases. You can increase the value for max_user_watches:

  echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
  

• Now install ZeroTier:

  curl -s https://install.zerotier.com | sudo bash
  

• Authorize the client at the ZeroTier website and give it a static IP (by adding an address to the machine by hand on the website instead of letting the site decide).

• Disable the ubuntu firewall:

  sudo ufw disable
  

  Now try to connect to the VM with SSH on its ZeroTier address be fore proceding. It could take a while before the virtual network is up & running, also after rebooting!

• Set a password for your user, you will need it to install packages from VSCode terminal; sudo passwd [your username]

• Download VSCode server from https://github.com/cdr/code-server/releases and install it:

  wget -q https://github.com/cdr/code-server/releases/download/v3.9.3/code-server_3.9.3_amd64.deb
  sudo dpkg -i code-server_3.9.3_amd64.deb
  

• Setup systemctl:

  systemctl --user start code-server
  systemctl --user enable code-server
  

• Configure authentication by editing ~/.config/code-server/config.yaml. Set up a strong password, you won't need to change the IP-binding since we'll be setting up a reverse proxy.

If you don't want to use the web interface and will only use SSH from another VSCode app you're basically ready, skip next steps to finish up.

If you do like to use VSCode from a browser, move on to install NGINX and optionally Let's Encrypt.

You need to set up a (sub)domain with an A record that points to the IP address assigned to the VM. For this tutorial I set up vscode.syntacticsugar.nl with a TTL of 60 seconds to ensure it's available quickly. You can change the IP to the IP you've assigned from ZeroTier in a later stage.

Install Let's Encrypt

sudo apt install certbot -y

Request a certificate

certbot certonly --standalone --agree-tos -m <enter your email> -d <the domain you set up>

This could fail the first few times as DNS updates tend to be slower whenever you need them to be fast.

When the certificate has been successfully created, change the DNS to the IP address you assigned in ZeroTier.

NGINX reverse (SSL) proxy

• Install NGINX

  sudo apt install nginx -y
  

• Create a config

  cd /etc/nginx/sites-available/
  sudo vim code-server
  

• If you have setup SSL, paste this config (and change ) :

server {
 listen 80;
 server_name <YOUR DOMAIN>;
 return 301 https://$server_name:443$request_uri;
}

server {
 listen 443 ssl http2;
 server_name <YOUR DOMAIN>;

 ssl_certificate /etc/letsencrypt/live/<YOUR DOMAIN>/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/<YOUR DOMAIN>/privkey.pem;

 location / {
 proxy_pass http://127.0.0.1:8080/;
 proxy_set_header Host $host;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection upgrade;
 proxy_set_header Accept-Encoding gzip;
 }
}

• Activate the vhost

  sudo ln -s /etc/nginx/sites-available/code-server /etc/nginx/sites-enabled/
  

• Check the config

  sudo nginx -t
  

• If all's fine, restart the services;

  sudo systemctl restart nginx
  sudo systemctl enable nginx
  

Check if you can reach code-server from your browser by going to https://yourdomain

Harden the firewall of your VM in the Azure Portal in the Networking Section. If you dare to rely on your ZeroTier connection you can disable SSH completely. If you're not the daring type consider only allowing connections to SSH from your own company or home IP. Also remove the rule for port 80. If you are planning to use VSCode from a browser outside ZeroTier you can leave port 80 and add an allow rule for port 443. This is NOT recommended from a security point of view.

Optional steps

So basically you have a VSCode server running! Hurray! Next would be installing the toolset you need for the language your're working with. I'm sticking with NodeJS, so the following steps only apply if you want to work with Node.

Install NVM (node version manager, check https://github.com/nvm-sh/nvm for the latest version)

curl -o- [https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh](https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh) | bash

Setup paths

nano ~/.zshrc

Paste the following config at the end of the file:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

Reload your environment:

source ~/.zshrc

install the Node.js version you want to use (to list al available versions, use nvm ls-remote):

nvm install v16.4.2

Connecting VSCode from your local machine with VSCode server

Install the VSCode Remote Development extension pack. Open VSCode and click "Open Remote window" at the most bottom left corner

Select Open SSH Configuration File and select the config file in your home-directory/.ssh

Add the following configuration (and modify it to reflect your environment):

Host [the hostname you used to create ssl or the Zerotier IP address ]
HostName [the ZeroTier Ip address]
User [your username]
IdentityFile ~/.ssh/id25519 [or the SSH private key file you use to connect]

Now click the same button Open Remote window , select Connect to host and select the host you just added.

If all is fine you should get an empty VSCode window, the button has changed and shows SSH: [hostname].

Congrats; you are now working on your VSCode server!

Plugins

Open the plugins tab and scroll through the windows with locally installed plugins. Click Install in SSH: [hostname] to install them on your VSCode server. You probably need to close VSCode and reconnect.

Tips and tricks and daily usage

Getting started in the morning

I have not found an easy way to autostart my VM every morning. To be honest; I don't think I need that either. I have days with back to back meetings and I don't want the VM burning to my Azure credits without me using it. So I login to the Azure portal and start it manually every time I need it. When it's up and running I connect my local VSCode app and hack away. Update: I stumbled upon the Azure App for iOS, this app makes it very easy to start your development VM.

Portmapping

If you run a project using node you'd normally fire up a browser and navigate to http://localhost:port . Using VSCode server is exactly the same! VSCode will create SSH tunnels for you so you can connect to localhost:portnumber. So you won't run into CORS issues or other strange behaviour.

Opening a VSCode window from the VSCode terminal

Imagine; you are working on a frontend from on your VSCode server from a local VSCode instance using SSH. You realize you need to check some stuff in another project, which has been cloned into another folder on your VSCode server. You can cd to that project using the terminal within VSCode and fire up a new editor by simply typing code .

Finishing up for the day

You had a productive day writing elegant code and finishing several tickets. You're ready for a quiet evening doing other stuff. Before closing the lid of your laptop be sure to save ALL files in VSCode and commit & push your work. Your VM will shut down later tonight which could lead to data loss. I have not run into this, but better safe than sorry right?

Known Issues

• It could take a while for ZeroTier to connect after booting the server. If you have issues ZeroTier not connecting at all try to login using SSH with the dynamic IP assigned by Azure and run ZeroTier join command; sudo zerotier-cli join <your network-id from ZeroTier>
• The VSCode webinterface might work better if you use Chrome.
• Not enough memory? Enable swap on your Azure VM; edit /etc/waagent.conf. add or uncomment these lines (set SwapSizeMB to match the amount of RAM your VM or more) :

  ResourceDisk.Format=y
  ResourceDisk.Filesystem=ext4
  ResourceDisk.MountPoint=/mnt/resource 
  ResourceDisk.EnableSwap=y
  ResourceDisk.SwapSizeMB=4096
  

  reboot your VM and you should see swap memory in top

Questions? Praise? Complaints?

Email: ivo@syntacticsugar.nl Twitter: https://twitter.com/buttonfreak

No need for scanning vulnerabilities and no brute-forcing.
Just log on and you’re home network is exposed!

Besides my data being uploaded to some Chinese server, which I really don’t like, I also noticed the default WIFI-settings are very weak and can be guessed without any need for password-lists.

By default the inverter stays in AP mode visible as “Solar-Wifi”, even when connected to your home network, with password “12345678”.

via GIPHY

After getting the connection all you need to do is find out which gateway you get assigned from DHCP, browse to that address (probably http://10.10.100.253 ), enter “admin/admin” as username & password and you’re in.

via GIPHY

Shockingly the interface shows the password of the home network in clear text, so connecting and penetrating the connected network is very very easy.

Yes, my home network Wifi AP is called “homeland-security” :p

Several of our neighbors have the same inverter, all of them have their wifi exposed and none of them have taken action to secure the inverter (up until now ;-)

Unfortunately you can’t disable the wifi-AP on the inverter itself, and you can’t change the admin-password to access the web-interface. You can however change the default wifi-password of the inverter which I strongly recommend.

Sidenote; the inverter software seems to think it’s not connected to a wifi-AP and reports having no connection, while it is connected and can be reached from the home network. This is probably a bug and might be responsible for keeping it’s own AP active and visible.

I’ve “reverse engineered” the latest Goodwe-API to allow syncing of power-data from Goodwe to pvoutput.org. It’s still “beta” but you can download and install the script from Github. Fortunately Goodwe dropped the old API which had no authentication at all and was easy to query for other users’ power-data (and location).

For my my next Goodwe-project I’ll be working on getting rid of the Goodwe-backends. I’ve already seen the values posted by the inverter by using an ARP-spoof, the data is transmitted unencrypted and with a simple HTTP-post, so creating a simple service in Node should not be very complex.