> 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 d32b109..663de70 100644
--- a/tutorials/epc-setup/index.html
+++ b/tutorials/epc-setup/index.html
@@ -191,10 +191,10 @@
MME
Edit the /etc/open5gs/mme.yaml file (as root or using sudo) as follows:
- Under mme: -> s1ap: -> server: -> address:, set the IP address you will assign to the network interface (likely an ethernet port) on your EPC computer which will be connecting to the eNB. In this tutorial (to match with the Network Configuration section that follows), we will use 192.168.150.1.
-- Under both mme: -> gummei: and mme: -> tai:, you will need to change the plmn_id (mcc and mnc values) to match the PLMN you are using for your network.
-- Note that for the purposes of eNB config later, the Tracking Area Code (or TAC) listed under tai: -> tac: will need to match the TAC number configured on the eNB (using the default of 1 is fine).
+- Under both mme: -> gummei: and mme: -> tai:, you will need to change the plmn_id: (mcc: and mnc: values) to match the PLMN you are using for your network. In SCN we use 315 for the MCC and 010 for the MNC, as explained in the "Quick explanation" below.
Quick explanation: "PLMN" refers to the Public Land Mobile Network, in which every network has to have a unique carrier ID defined by the 3-digit "mobile country code (MCC)" and a 2 or 3-digit "mobile network code (MNC)". Alternately, for iPhone compatibility in the US, SCN uses the CBRS "private LTE" PLMN assigned by Apple as described in this doc.
+- Note that for the purposes of eNB config later, the Tracking Area Code (or TAC) listed under
mme: -> tai: -> tac: will need to match the TAC number configured on the eNB (using the default of 1 is fine).
- Optional: Edit
network_name: (full and short) and mme_name: as desired. One of these names will show up on smartphones' lock screens as the "carrier" when the phone is attached to the network.
SGWU