Deploying FireEdge/UI to a Separate Server

Product Support Installation & Configuration
1

I’ve seen a few posts on this topic but the steps listed within weren’t helpful. Is there a detailed document on how to setup the UI on a separate server? I’m familiar with this one but it is too high level.

My experience thus far is I deploy the opennebula package to my front-end and then deploy opennenbula-fireedge and opennebula-guacd to a separate server. The relevant configurations I change are as follows:

On the FrontEnd Server:

/etc/one/oned.conf

PORT = 2633

LISTEN_ADDRESS = "0.0.0.0"

onezone show 0

ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula
STATE             : ENABLED


ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
ENDPOINT_GRPC="localhost:2634"

On the UI Server:

/etc/one/fireedge-server.conf

# FireEdge server IP
host: '0.0.0.0'

# FireEdge server port
port: '2616'

# OpenNebula: use it if you have oned and fireedge on different servers
one_xmlrpc: 'http://front-end.my.com:2633/RPC2'

# Guacamole daemon
guacd:
  port: 4822
  host: 'localhost'

# Local zone in a Federation setup
# This attribute must point to the Zone ID of the local OpenNebula to which this FireEdge belongs to.
default_zone:
  id: 0
  name: 'OpenNebula'
  endpoint: 'http://front-end.my.com:2633/RPC2'

I previously tried also updating the zone on the front-end to use an IP address rather than localhost.
In all of these cases, requests to the UI server at http://ui.my.com:2616 hang with no response. I’ve dialed up the debuggin in the fireedge config file to 5 and don’t get any useful messages. No idea why this isn’t working, I can only imagine I’m missing something.

The machines are in the same subnet (no firewall) and do not have IPTable rules or UFW set up. I’m running Ubuntu Linux 24.04.

I’ve tried replacing the DNS FQDNS with IPs in all of the relevant places to no avail.

I’m missing something, but I don’t know what. Any ideas? Thanks!

Additional Details:

I’m running OpenNebula version 7.2

I do see an error occasionally pop up in the UI Fireedge server log, but it’s incomplete so I’m unsure what the issue is:

Error: No forecast configuration files found
    at getForecastConfig (/usr/lib/one/fireedge/dist/index.js:1:133560)
    at /usr/lib/one/fireedge/dist/index.js:1:125220
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Is there something I need to copy over from the front-end server? I did have to copy over the sunstone_auth file already.

2

Hi Brandon,

One thing to clarify first: 2633 is the OpenNebula XML-RPC port, not the FireEdge UI port. If FireEdge is configured with:

host: '0.0.0.0'
port: '2616'

then the UI should normally be accessed through:

http://ui.my.com:2616/fireedge/sunstone

not through http://ui.my.com:2633.

I would suggest checking the connectivity in both directions first.

From the UI / FireEdge server, check that it can reach the OpenNebula frontend XML-RPC endpoint:

curl -v http://front-end.my.com:2633/RPC2

From the frontend, check that it can reach FireEdge:

curl -v http://ui.my.com:2616/fireedge/sunstone

Also on the UI server, verify that FireEdge is listening on the expected port:

ss -lntp | grep 2616
systemctl status opennebula-fireedge

Regarding the copied file, yes, the UI server needs access to the same sunstone_auth credentials used by FireEdge to authenticate against OpenNebula. Please make sure this file exists on the UI server:

/var/lib/one/.one/sunstone_auth

and has the correct ownership/permissions:

chown oneadmin:oneadmin /var/lib/one/.one/sunstone_auth
chmod 600 /var/lib/one/.one/sunstone_auth

Your one_xmlrpc value in fireedge-server.conf looks correct:

one_xmlrpc: 'http://front-end.my.com:2633/RPC2'

The No forecast configuration files found message does not look directly related to the UI hanging on port 2633. I would first test access through port 2616 and confirm the XML-RPC connectivity from the UI server to the frontend.

3

Thanks for the reply! Yes, you are correct about port 2616. I corrected my post above (typo).

I did copy the sunstone_auth file from the front-end over to the UI server.
I did actually get this working, and it actually had everything to do with those missing forecast files. Once I created the following files on the UI server, it started responding:

  • /var/lib/one/remotes/etc/im/kvm-probes.d/forecast.conf
  • /var/lib/one/remotes/etc/im/lxc-probes.d/forecast.conf
  • /var/lib/one/remotes/etc/im/qemu-probes.d/forecast.conf

The conf files are all identical at the start, so I just took a copy of one of them from the front-end server and replicated it to the three destination paths above and it worked.

So, for someone else’s reference, to setup a separate UI server on version 7.2, it appears you:

  • Install the opennebula-fireedge package
  • Create the following folders (change the owner to oneadmin:oneadmin, set permissions to 0600)

      • /var/lib/one

      • /var/log/one

      • /usr/lib/one

      • /etc/one

      • /var/lib/one/remotes/etc/im/kvm-probes.d

      • /var/lib/one/remotes/etc/im/lxc-probes.d

      • /var/lib/one/remotes/etc/im/qemu-probes.d

  • Copy /var/lib/one/.one/sunstone_auth from front-end server
  • Configure the /etc/one/fireedge-server.conf file
    • Set one_xmlrpc to http://{{ frontend_server_fqdn_or_ip }}:2633/RPC2
    • Set default_zone.endpointto http://{{ frontend_server_fqdn_or_ip }}:2633/RPC2
  • Copy the forecast files specified above to the UI server.
  • Restart the opennebula-fireedge service

Now the UI comes up. I’ll keep testing and amend the above if I find more.

4

Thanks for the update, this is very useful.

Good catch regarding the forecast files. I agree this explains why the previous error was relevant after all, especially since FireEdge started responding once these files were present:

/var/lib/one/remotes/etc/im/kvm-probes.d/forecast.conf
/var/lib/one/remotes/etc/im/lxc-probes.d/forecast.conf
/var/lib/one/remotes/etc/im/qemu-probes.d/forecast.conf

So for a separated FireEdge/UI node, besides sunstone_auth and the fireedge-server.conf XML-RPC endpoint, FireEdge also needs the expected remotes configuration tree to exist locally.

5

For completeness, I also had to complete a step detailed by another user on the forum:

On the front-end server:

su - oneadmin
onezone update 0 --append

# The VI editor will open up, and edit the contents of the template file:
ENDPOINT="http://{{ frontend_server_fqdn_or_ip }}:2633/RPC2"
ENDPOINT_GRPC="{{ frontend_server_fqdn_or_ip }}:2634"
6

Hi Brandon,

We reproduced and validated this setup on OpenNebula 7.2.1 with a dedicated Ubuntu 24.04 FireEdge server.

There were two important details missing from the minimal package-only setup:

  1. The dedicated FireEdge server needs /var/lib/one/.one/sunstone_auth copied from the frontend, with oneadmin:oneadmin ownership and 0600 permissions.

  2. FireEdge also expects the local IM configuration tree to exist. In our test, the UI did not work correctly until we copied:

/var/lib/one/remotes/etc/im

from the frontend to the dedicated FireEdge server.

Otherwise FireEdge may start, but the logs can show errors such as:

ENOENT: no such file or directory, scandir '/var/lib/one/remotes/etc/im/'

or:

No forecast configuration files found

Zone 0 should not use localhost as the endpoint when FireEdge is remote. On the frontend, check:

onezone show 0

and make sure the zone template points to an address reachable from the FireEdge server, for example:

ENDPOINT="http://<frontend-ip>:2633/RPC2"
ENDPOINT_GRPC="<frontend-ip>:2634"

After copying the files and updating the endpoint, restart opennebula-fireedge and access the UI through:

http://<fireedge-server>:2616/fireedge/sunstone

We are preparing a KB article with the complete step-by-step procedure.