IMPORTANT IF YOU CHANGE THE PASSWORDS OF ANY OF STAGE/PROD YOU NEED TO PUT THE NEW ONES IN GITEA-Secrets AS "STAGE-SSH-PASSPHRASE" AND "PROD-SSH-PASSPHRASE"
You can add them into the Gitea Actions Pipeline, read the documentation on Github-actions and integration tests.
Runner:
The runner runs our automatic deployment, every push on main for stage and every push including a v1.* version tag for production!
If the runner is not running, ssh into it and use the command sudo ./act_runner daemon in the ubuntu home directory.
If you need to see it in gitea it's under Actions->Runners
It follows the instructions in stage-deploy.yaml and prod-deploy.yaml in the /.gitea folder.
Gitea:
It's our github, you are all admins, don't stop/delete this service we don't have a backup as of now. (Maybe make one)
Webserver-Front-Back:
This is our production webserver it's setup is identical to the staging one.
Nginx/conf.d configuration file. Certbot is used for the ssh certificate and should automatically renew it.
in ~/backend there are the files from any backend compile/release and a service file. DON'T DELETE THE SERVICE FILE.
in ~/frontend the npm build release files are stored, the static main page needs to be copied to /var/www...etc the deploy does this.
Stage:
See above for Production.
Notes on the Backend:
Our Backend-Salt is not sufficient, use a random 10 letter string appended instead and remove it for checks...I might do this before I go.
Check the program.cs and the Controller.cs for everything, everything is in there.
We load our database in memory and save a copy after every change - This allows us for fast querying but if the db or the number of changes get big you might need to patch this out
We revoke the S3-Bucket read-keys once a day, these are per-installation not per user and for each installation we have 2 IAM-Roles one for generating read-keys and one for generating write keys.
Write Keys are not to be changed! They would have to be set on each installation manually again. -> We need to automate this in the future.
Vrm-Grabber:
The Vrm-Grabber is hosted on vrm.innov.energy.
It's code is fairly simple so go ahead and read it. It's basically a small backend that serves a dynamically generated table.
It grabs all the installation from Victrons vrm and displays a couple of basic things about them.
It changes the device-names to match the installation names!
It allows for updating all the batteries, just rename the FirmwareVersion and give it the new file.
Make sure to change the Victron-Alarms, they are automatically set on the update so just change them in the program!
It's useful for ssh-ing into them or checking for problems.
Updating it's db takes forever as Victron has a call-limit, it normally goes through the list once every ~8 hours so the online status is slow to catch up.
On startup it randomises the list of installations, if the program crashes frequently and gets restarted by the watchdog we will still update all the installations.
S3Explorer:
This is a simple CLI-tool you can use to grab data from our Salimax-Installation buckets. Try it it's simple. Find its -secret.
Python:
I'd recommend all of you to take a look at lsdbus dbus-spy and dbus-log they are invaluable for debugging installations and Ivo and I put a lot of effort into them.
upload-bms-firmware could use a rewrite but it works as of now...
make_deploy
My first work here don't judge it to harshly. It is used to prepare a tar file, which on a usb-stick plugged into any Victron installation on startup will update it to include our software and scripts.
It's useful if you have physical access to an installation.
