-
Notifications
You must be signed in to change notification settings - Fork 261
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
Comments
Thanks for reporting. What is the location of your |
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. |
Yes that would be the workaround.
Yes, this was introduced recently. We could add an option in the config file, similar to the
Indeed, I think we should add this config option as well.
I am going to review this and see what we can do. Thanks again for catching these problem 👍 |
I have the same or similar problem with 2.2.45.
and the server process runs as user When I click "New Template", "Update from online registry" in the GUI, the server downloads files to I also see some old appliance files under The workaround is to comment out the I know this is the case because:
I think there must be some part of the code which is not using the EDIT: I suspect here:
|
@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
I think this issue is fixed now. |
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:
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?
The text was updated successfully, but these errors were encountered: