66 lines
4.4 KiB
Plaintext
66 lines
4.4 KiB
Plaintext
Password for my computer: 123/*.
|
|
There are 2 bootable partitions: kubuntu and Nixos
|
|
The Nixos Setup files are on the usb stick on my desk if needed.
|
|
Exoscale-Compute instances are our servers for production/stage/a runner for the automatic deployment and our gitea instance.
|
|
All of them should be running! - There is no harm in restarting them if you need the password but you should leave your ssh key in there!
|
|
|
|
|
|
!!!!!!!!!!!!!
|
|
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"
|
|
!!!!!!!!!!!!
|
|
|
|
|
|
I'll reroute my emails to one of you for software updates.
|
|
|
|
|
|
MARIOS: Please make sure to patch out the vulnerable npm packages in the frontend.
|
|
And in my opinion, get started on React or Testcafe Integration tests ;)
|
|
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. |