Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

appliances_path no longer read/honored from config file #2226

Closed
ghost opened this issue May 24, 2023 · 5 comments · Fixed by #2394
Closed

appliances_path no longer read/honored from config file #2226

ghost opened this issue May 24, 2023 · 5 comments · Fixed by #2394

Comments

@ghost
Copy link

ghost commented May 24, 2023

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 grossmj added the Bug label May 27, 2023
@grossmj
Copy link
Member

grossmj commented May 27, 2023

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
Copy link
Author

ghost commented May 28, 2023

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
Copy link
Member

grossmj commented May 30, 2023

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 👍

@candlerb
Copy link
Contributor

candlerb commented Jan 25, 2024

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")

@grossmj grossmj linked a pull request Jul 8, 2024 that will close this issue
@grossmj
Copy link
Member

grossmj commented Jul 8, 2024

@candlerb this problem should have been fixed in more recent versions however please open a new issue if it still doesn't work. Thanks.

I have added 2 new settings to configure in the gns3_server.conf file.

  • install_builtin_appliances can be configured to prevent the server to install the built-in appliances. By default, built-in appliances are installed in resources_path/appliances
  • resources_path can be configured to choose to store resources (files that are not meant to be edited) in a given location instead of the default local user directory.
; Path where files like built-in appliances and Docker resources are stored
; The default path is the local user data directory
; (Linux: "~/.local/share/GNS3", macOS: "~/Library/Application Support/GNS3", Windows: "%APPDATA%\GNS3")
; resources_path = /home/gns3/GNS3/resources

; Install built-in appliances
install_builtin_appliances = True

I think this issue is fixed now.

@grossmj grossmj closed this as completed Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants