smhk

Open5GS: Change WebUI IP and port

TL;DR: To change the IP and port used by Open5GS’s WebUI, modify the service file to set HOSTNAME=x.x.x.x and PORT=yyyy for the Environment field.

Situation §

  • The Open5GS WebUI binds to localhost:9999 by default.
  • In general, the Open5GS documentation is excellent, however I could not find documentation on how to change the IP and port used by the WebUI.
  • I needed to change the bind IP from localhost to 0.0.0.0 so that the WebUI is accessible from outside of the core.

Solution §

The Open5GS WebUI IP and port can be changed by modifying the open5gs-webgui.service file as follows1:

/lib/systemd/system/open5gs-webgui.service
[Unit]
Description=Open5GS WebUI
Wants=mongodb.service mongod.service

[Service]
Type=simple

WorkingDirectory=/usr/lib/node_modules/open5gs
Environment=NODE_ENV=production HOSTNAME=0.0.0.0 PORT=3000
ExecStart=/usr/bin/node server/index.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

Then run:

# Reload the service files
sudo systemctl daemon-reload

# Restart the WebUI
sudo systemctl restart open5gs-webgui.service

Then run systemctl status open5gs-webgui.service to check in the logs:

> Ready on http://0.0.0.0:3000

The Open5GS WebUI is now bound to IP 0.0.0.0 on port 3000!

Addendum: Copilot conversation §

Before figuring out the solution, I had thought this issue would be a good question to try with Copilot. So I asked Copilot:

In Open5GS, how do I change which IP address the webui binds to?

Copilot told me to modify the config file at /etc/open5gs/webui.yaml. This seemed like a very sensible suggestion given that all the other 5G core components have a corresponding YAML config file: AMF has amf.yaml, SMF has smf.yaml, UPF has upf.yaml and so on (16 in total). So logic dictates that the WebUI would have a webui.yaml, right?

In fact, before even asking Copilot for help, I had already checked for a webui.yaml since following this pattern myself I assumed there would be one; but there was not. So, after Copilot seemingly drew the same conclusion and told me to modify the webui.yaml file, I let Copilot know that file does not exist. It responded by blaming the installation process and suggesting I create the webui.yaml file.

I decided to give it a try, created webui.yaml and populated it with the suggested YAML:

webui:
    - addr: 0.0.0.0
      port: 3000

Then I restarted the WebUI service, and sure enough, the config did not work. The WebUI was still bound to localhost:9999.

At this point I asked Copilot to reconsider:

Are you sure that webui.yaml is real? I know that other Open5GS components have corresponding config files (e.g. the AMF has amf.yaml), but as far as I can tell, the webui does not have a webui.yaml.

Copilot realised its mistake, and suggested that instead I modify the open5gs-webui.service file to pass in the arguments --addr 0.0.0.0 --port 3000 as part of the ExecStart command. This did not work for me either, but I did some more research (outside of Copilot) and found the HOSTNAME and PORT environment variables were supported.2

Having figured out the solution, I shared the news with Copilot. It responded by agreeing with the solution, and sharing the steps written up in full.

Thoughts §

It was interesting that Copilot made the same (incorrect) assumption as I did: that a webui.yaml config file was very likely to exist given the structure of Open5GS3. However, Copilot did not figure out that this assumption is wrong until I forced it to reconsider. Even then, it suggested using --addr 0.0.0.0 --port 3000 which is very plausible but, crucially, wrong.

Were this a subject area in which I had less expertise, it would likely have taken longer to realise I was being confidently lead astray.

Chat log §

For reference, following is the full chat log of the above conversation with Copilot:

Screenshot of chat with Copilot.
Screenshot of chat with Copilot. The imprint “AI-generated content may be incorrect”, shown at the bottom of every response from Copilot, remains indisputable.

Addendum: Claude conversation §

For comparison, I posed the same question to Claude.

At first it suggested that I modify the source code. After specifying that I wanted to modify configuration and not code, it was then able to suggest setting the HOSTNAME and PORT environment variables.

Thoughts §

Claude got to the right answer with less guidance, but I was surprised that it started suggesting I modify the source of the WebUI.

Chat log §

For reference, following is the full chat log of the above conversation with Claude:

Screenshot of chat with Claude.
Screenshot of chat with Claude.

  1. Editing the open5gs-webgui.service file is not ideal since it requires sudo, feels like hard-coding, and requires a daemon-reload to take effect. A config file would be preferable. But as detailed later in this note, there is no config file for the WebUI, instead environment variables are used. So, an alternative solution may be to update the service file to source a custom config file which defines the environment variables, but then we are deviating even further from the normal Open5GS WebUI deployment. In this case, my setup is temporary, so editing the service file directory seems acceptable. ↩︎

  2. For evidence of the HOSTNAME and PORT environment variables used by the Open5GS WebUI, see webui/server/index.js in the Open5GS repo, which calls const _hostname = process.env.HOSTNAME || 'localhost'; and const port = process.env.PORT || 9999;↩︎

  3. Even as I write this, the presence of a webui.yaml seems so likely that I start to doubt myself! To settle this, let’s look at the Open5GS source code. Here are all the “base” config files, e.g. amf.yaml.in (which becomes amf.yaml). There is no webui.yaml.in. However, the WebUI is actually a separate optional component. It lives here in the Open5GS repo, but has to be installed with some additional steps. There are no config files anywhere in the webui/ directory. Finally, there are zero mentions of webui.yaml in the Open5GS repo, and (at time of writing) searching online for "open5gs" "webui.yaml" has zero results. In future this query may lead to this very note! ↩︎