> librenms.sql","title":"Backing Up"},{"location":"tutorials/librenms/deploy/","text":"Deploying I wrote a script to deploy libreNMS with the configuration that SCN uses. The repo is here Software requirements Only tested on debian and ubuntu. Not sure what else it works on but it could work on other linux distros Steps Install docker if it is not installed already Install docker compose if it is not installed already Instal unzip if it is not installed already Check out this repo If you want to restore a previous install, provide a sqldump named librenms.sql flat in this checked out repo. There is a helper script called get_database_from_currently_running_server.sh to get the database off of the non dockerized install (needs ssh access to the server) If you want to restore the graphs too, you can provide a file named rrd.zip flat in the checked out repo which is just the rrd folder ziped up. There is a helper script called get_rrd_zip_from_currently_running_server.sh to get the rrd zip from the non dockerized install (needs ssh access to the server) Run ./deploy.sh builds the librenms image builds the database image with/without the backup Starts the service using docker compose . This creates 2 shared volumes in the compose directory The librenms folder is for the librenms docker images to share configuration data including rrd files The db volume is the database unzips the rrd folder in the rrd directory of the shared librenms volume The UI will run on port 8000","title":"Deploying"},{"location":"tutorials/librenms/deploy/#deploying","text":"I wrote a script to deploy libreNMS with the configuration that SCN uses. The repo is here","title":"Deploying"},{"location":"tutorials/librenms/deploy/#software-requirements","text":"Only tested on debian and ubuntu. Not sure what else it works on but it could work on other linux distros","title":"Software requirements"},{"location":"tutorials/librenms/deploy/#steps","text":"Install docker if it is not installed already Install docker compose if it is not installed already Instal unzip if it is not installed already Check out this repo If you want to restore a previous install, provide a sqldump named librenms.sql flat in this checked out repo. There is a helper script called get_database_from_currently_running_server.sh to get the database off of the non dockerized install (needs ssh access to the server) If you want to restore the graphs too, you can provide a file named rrd.zip flat in the checked out repo which is just the rrd folder ziped up. There is a helper script called get_rrd_zip_from_currently_running_server.sh to get the rrd zip from the non dockerized install (needs ssh access to the server) Run ./deploy.sh builds the librenms image builds the database image with/without the backup Starts the service using docker compose . This creates 2 shared volumes in the compose directory The librenms folder is for the librenms docker images to share configuration data including rrd files The db volume is the database unzips the rrd folder in the rrd directory of the shared librenms volume The UI will run on port 8000","title":"Steps"},{"location":"tutorials/librenms/upgrade/","text":"Upgrading Upgrading can be segmented into 2 parts. The container OSses and the service OS Each container runs an OS - The Maria db container is based on ubuntu, so you can just do sudo apt update and sudo apt upgrade when executing bash on the container - The Redis container for some reason only has an ash executable installed on the container. Also it runs on alpine so it can be updated using apk update and apk upgrade - The libreNMS and the libreNMS dispatcher container is instantiaated on the same container which is on alpine, and uses bash. Update as usual for alpine installs. Service I think that libreNMS vends a script called daily.sh (librenms docs here ) that is added to the cron, but cron is not running on docker containers since each container only runs one process. Even if we manually run daily.sh, there are errors. I think that the docs also give a manually manual way to update, by doing a git clone, but since the librenms files were not pulled using git, we cant use this way. I tried using rsync to overwrite the old files with the new files, but there are some issues. The nuclear option can be used, which is remove the containers, build new updated ones, and start that, but this will include a small outage Go to the compose directory and run sudo docker compose down to stop and remove all the containers. We store data (rrd files and the database) in a docker volume inside the compose directory anyway so we should not need to worry about removing containers removing any data Go to the librenms_image directory, change the version of the image to the latest version here run sudo docker build . -t scn-librenms , which should build the new image go to the db_image directory and update the Dockerfile's version to the latest version here run sudo docker build . -t scn_mariadb_librenms go to the compose directory and update the compose.yml file to use the latest redis release here Then you should be able to start the service with a sudo docker compose -f compose/compose.yml up -d The service should come up as it was before. If it does not, you may have to do a ./lnms migrate","title":"Upgrading"},{"location":"tutorials/librenms/upgrade/#upgrading","text":"Upgrading can be segmented into 2 parts. The container OSses and the service","title":"Upgrading"},{"location":"tutorials/librenms/upgrade/#os","text":"Each container runs an OS - The Maria db container is based on ubuntu, so you can just do sudo apt update and sudo apt upgrade when executing bash on the container - The Redis container for some reason only has an ash executable installed on the container. Also it runs on alpine so it can be updated using apk update and apk upgrade - The libreNMS and the libreNMS dispatcher container is instantiaated on the same container which is on alpine, and uses bash. Update as usual for alpine installs.","title":"OS"},{"location":"tutorials/librenms/upgrade/#service","text":"I think that libreNMS vends a script called daily.sh (librenms docs here ) that is added to the cron, but cron is not running on docker containers since each container only runs one process. Even if we manually run daily.sh, there are errors. I think that the docs also give a manually manual way to update, by doing a git clone, but since the librenms files were not pulled using git, we cant use this way. I tried using rsync to overwrite the old files with the new files, but there are some issues. The nuclear option can be used, which is remove the containers, build new updated ones, and start that, but this will include a small outage Go to the compose directory and run sudo docker compose down to stop and remove all the containers. We store data (rrd files and the database) in a docker volume inside the compose directory anyway so we should not need to worry about removing containers removing any data Go to the librenms_image directory, change the version of the image to the latest version here run sudo docker build . -t scn-librenms , which should build the new image go to the db_image directory and update the Dockerfile's version to the latest version here run sudo docker build . -t scn_mariadb_librenms go to the compose directory and update the compose.yml file to use the latest redis release here Then you should be able to start the service with a sudo docker compose -f compose/compose.yml up -d The service should come up as it was before. If it does not, you may have to do a ./lnms migrate","title":"Service"}]}
\ No newline at end of file
diff --git a/tutorials/epc-setup/index.html b/tutorials/epc-setup/index.html
index 53d3f5c..da9713c 100644
--- a/tutorials/epc-setup/index.html
+++ b/tutorials/epc-setup/index.html
@@ -180,7 +180,7 @@ Software Components
We would also recommend running the optional WebUI (Web User Interface) service: open5gs-webui.service.
The following steps will walk you through this installation process.
Step 1: Open5GS Install Notes
-We install Open5GS following the Open5GS Quickstart documentation based on your operating system and desired implementation (e.g. "bare metal" directly on the operating system vs. Docker).
+
Install Open5GS following the Open5GS Quickstart documentation based on your operating system and desired implementation (e.g. "bare metal" directly on the operating system vs. Docker).
There are even VoLTE and Dockerized VoLTE implementations of Open5GS.
A similar step-by-step tutorial to this one can be found here.
In SCN we have run Open5GS successfully using Ubuntu 20.04 and 22.04, on bare metal or in Virtual Machines, installed via the apt package manager.
@@ -234,7 +234,7 @@
A. Recommended
The "downstream" ethernet interface (enp4s0) connected to the eNB is assigned two IP addresses and
subnets, which are configured statically (not by DHCP, hence the dhcp4: no).
In our case, we need this interface to talk to the Baicells Nova 233 eNB we use.
-Our eNB has the default local (LAN) IP address of 192.168.150.1. We also need to set its WAN address (for whatever reason this is required to be different) to 192.168.151.1, as in this eNB setup tutorial. That's why we have the addresses: section that sets the static IP addresses of the EPC to 192.168.150.2/24 and 192.168.151.2/24. Since these IP addresses are in the same subnet as the eNB IP addresses, they will be able to talk to each other automatically without a router in between helping to route communications packets between the two addresses.
+Our eNB has the default local (LAN) IP address of 192.168.150.1. We also need to set its WAN address (for whatever reason this is required to be different) to 192.168.151.1, as in this eNB setup tutorial. That's why we have the addresses: section that sets the static IP addresses of the EPC to 192.168.150.2/24 and 192.168.151.2/24. Since these IP addresses are in the same subnet as the eNB IP addresses, they will be able to talk to each other automatically without a router in between helping to route communications packets between the two addresses.
Below we also provide an alternate configuration in case you do not yet have a
machine with 2 ethernet ports or a USB to ethernet adapter dongle. However, only
the first configuration is recommended for deployments for security reasons.