Blank registryUrl value results in Kibana 404 error

[senatesan]

Version

2.4.160

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Meets minimum requirements

CPU

8

RAM

16

Storage for /

64.5

Storage for /nsm

123.6

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

SO 2.4.160 with Elastic Enterprise License.

I modified the Fleet registry URL in the SOC Administration>Configuration>kibana>config>xpack>fleet>registryUrl

I added the value https://epr.elastic.co and ran a highstate.

I then deleted the value and ran another highstate.

Actual Behavior:
This led to Kibana displaying 404 page not found. Although so-status showed so-kibana was running.

I noticed that /opt/so/saltstack/local/pillar/kibana/soc_kibana.sls had changed the value to ""

Also in the logs, I noticed:

/opt/so/log/soc/sensoroni-server.log:{"fields":{"requestId":"3758ddc8-851b-4c3e-aa08-0f3dd214d420","settingId":"kibana.config.xpack.fleet.registryUrl","settingLength":0,"settingPath":"/opt/so/saltstack/local/pillar/kibana/soc_kibana.sls"},"level":"info","timestamp":"2025-08-01T11:52:19.574170616Z","message":"Updating setting to new value"}

Expected Behavior:
When the value for registryUrl is blank, the soc_kibana.sls should have the registryUrl configuration removed instead of being set to "".

Workaround Fix:
I had to remove all the contents from my soc_kibana.sls file and run another highstate to restore access to Kibana.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[senatesan]

I'd like to add that if you do add a custom registryUrl and then the Security Onion manager loses internet connection for whatever reason, i.e. temporary internet outage, moved to air-gapped environment, etc. the result is a 404 error on the Fleet page.

[reyesj2]

We host the package registry locally on the manager. What are you looking to accomplish by pointing to an external registry? Just the latest package upgrades available?

[senatesan]

Yes, updates to the integrations and the elastic agent itself.

[reyesj2]

in that case you might be interested in https://www.elastic.co/docs/reference/fleet/air-gapped#air-gapped-diy-epr

[Jacob-gr]

I have also encountered this bug.

I think the big issue is that even when you clear out kibana.config.xpack.fleet.registryUrl in the SOC, the underlying soc_kibana.sls file is not cleared out or reset to use the default built-in Security Onion package registry.

Currently, this line in the Kibana map.jinja file handles the logic to set the default Security Onion package registry. In the jinja, if the kibana.config.xpack.fleet.registryUrl is not set in the soc_kibana.sls file, it will default to the SO package registry.

However, if kibana.config.xpack.fleet.registryUrl is ever modified in the SOC and then cleared out, the kibana.config.xpack.fleet.registryUrl object still exists in soc.kibana.sls. The registryUrl is set to an empty string. However, because the jinja logic is only checking for this object to exist and not validating it is a string with len > 0 (or whatever other validation logic would be necessary) it will not apply the default Security Onion package registry.

Thus, the default Security Onion package repository is not applied and Kibana bricks because it does not have a valid configuration.

This is an issue because the kibana.config.xpack.fleet.registryUrl is available to modify in the SOC. A user might attempt to modify this setting to use their own registry, but if they ever decide to go back to the default, this is not possible. I think the expected behavior of clearing out kibana.config.xpack.fleet.registryUrl would be for Security Onion to use its own default package registry, but this behavior does not occur due to the jinja logic.

[reyesj2]

You can also hit the 'reset to default' button and that will restore it to the default config which points to a self hosted epr.

[defensivedepth]

I've created an issue to get this fixed.

[defensivedepth]

@Jacob-gr @senatesan I am closing this issue without any changes because @reyesj2 is correct - this is not a bug, you just need to click the reset to default button in the config pane and that will restore it to the default config.