appliances_path no longer read/honored from config file

[ghost]

We recently upgraded GNS3 to 2.2.39 after running on 2.2.34 for some time. After the upgrade the gns3 service no longer starts. The log file complains about a permission issue:

CRITICAL web_server.py:88 Could not start the server: [Errno 13] Permission denied: '/etc/appliances'

we have specified a custom appliances folder which would have the correct permissions in the config file:

; Path where user appliances are stored
appliances_path = /srv/gns3/appliances

What might be a bit special is that we run gns3 under the gns3 user and put pretty much everything into a folder undr /srv/gns3 The systemd ExecStart looks like this: ExecStart=/usr/bin/gns3server --log /var/log/gns3/gns3.log --pid /var/run/gns3/gns3.pid --daemon --config /etc/gns3-server.conf

We are aware that the PID file should be relocated, but thats a cosmetic issue for now. Also we are not using any of the default GNS3 appliances and so far our appliance folder is intentionally empty.

If we create /etc/appliances and apply the correct permissions (e.g. change ownership to the gns3 user) the gns3 services starts, but this is only a workaround from our perspective.

This log line show that it install the default appliances to that folder INFO appliance_manager.py:102 Installing built-in appliances in '/etc/appliances' Expectation would have been, that it at least honors the path specified in the config file.

We have recreated the issue on a fresh install of 2.2.39 as well. Its running on Ubuntu 20.04.6 LTS using the gns3 deb packages.

Has there been any change to the way the appliances folder needs to be specified in the config file or to appliance handling in particular? We have seen a couple of mentions of appliance based changes in e.g. 2.2.36 and 2.2.37 Is there anything else we can/should provide to narrow down the problem?

[grossmj]

Is there anything else we can/should provide to narrow down the problem?

Thanks for reporting. What is the location of your gns3_server.conf? built-in appliances are actually installed in a appliances folder at the same location as the config file. appliances_path refers to the location where custom appliances are stored. I know this is confusing and I think we should make it more explicit.

[ghost]

The config files lives in /etc/ for now (as seen in the execstart line above) ... so that would explain that behaviour. So I guess for now the second option/workaround would be to colocate the config file into our custom directory as well.

Are we right to assume tha the behaviour to force install the built-in appliances was introduced recently? Is there a way to prevent that? As mentioned we are not using any of these appliances anyway and would not need them for now anyway.

It would also be very good to introduce a config option for where to put these files similar to the already existing appliances_path and other options.

And yes we agree that documenting that behaviour would also help, it definitaly is unexpected for us that the server tries to generate something in the folder where the config file lives.

[grossmj]

The config files lives in /etc/ for now (as seen in the execstart line above) ... so that would explain that behaviour. So I guess for now the second option/workaround would be to colocate the config file into our custom directory as well.

Yes that would be the workaround.

Are we right to assume tha the behaviour to force install the built-in appliances was introduced recently? Is there a way to prevent that? As mentioned we are not using any of these appliances anyway and would not need them for now anyway.

Yes, this was introduced recently. We could add an option in the config file, similar to the enable_builtin_templates we already have. We could name it install_builtin_appliances.

; Enable the built-in templates
enable_builtin_templates = True

It would also be very good to introduce a config option for where to put these files similar to the already existing appliances_path and other options.

Indeed, I think we should add this config option as well.

And yes we agree that documenting that behaviour would also help, it definitaly is unexpected for us that the server tries to generate something in the folder where the config file lives.

I am going to review this and see what we can do.

Thanks again for catching these problem :+1:

[candlerb]

I have the same or similar problem with 2.2.45. /etc/gns3/gns3_server.conf has:

[Server]
images_path = /var/lib/GNS3/images
projects_path = /var/lib/GNS3/projects
configs_path = /var/lib/GNS3/configs
appliances_path = /var/lib/GNS3/appliances
symbols_path = /var/lib/GNS3/symbols
report_errors = True

and the server process runs as user gns3 with home directory /var/lib/GNS3

When I click "New Template", "Update from online registry" in the GUI, the server downloads files to /var/lib/GNS3/.local/share/GNS3/appliances/ (they have today's timestamp) - but then the appliances are still not visible in the GUI.

I also see some old appliance files under /etc/gns3/appliances/ but with timestamps from last year.

The workaround is to comment out the appliances_path line from gns3_server.conf. Now the ones in /var/lib/GNS3/.local/share/GNS3/appliances/ are visible.

I know this is the case because:

• I've moved the /etc/gns3/appliances directory out of the way
• Clicking "Update from online registry" updates all the timestamps under /var/lib/GNS3/.local/share/GNS3/appliances/, and does not create a new /etc/gns3/appliances directory

I think there must be some part of the code which is not using the appliances_path when it is set.

EDIT: I suspect here:

./gns3server/controller/appliance_manager.py:        appliances_dir = os.path.join(platformdirs.user_data_dir(appname, vendor, roaming=True), "appliances")