PPA installs to a different location than specified by gns3.service.systemd

[eantowne]

Issue description:

When installing from PPA, gns3server is installed as /usr/share/gns3/gns3-server/bin/gns3server and a link is created as /usr/bin/gns3server. The path for gns3server specified in init/gns3.service.systemd is /usr/local/bin/gns3server.

This results in a PPA install and configuration as a daemon will fail when trying to start the service.

The GNS3 VM uses /usr/local/bin/gns3server.

Recommendation:

If possible change PPA install location or add a link in the location specified by the gns3.service.systemd file during the PPA installation process.

[grossmj]

We do not use the PPA in the GNS3 VM. GNS3 is installed from sources using sudo python3 setup.py install

Not sure about changing the paths since:

/usr/bin is for distribution-managed normal user programs. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages.

Were you trying to install PPA packages in the GNS3 VM?

[eantowne]

@grossmj This was a PPA install on a bare-metal Linux installation. When installing from PPA the gns3.service.systemd is not present on the file system. The documentation specifies that gns3.service.systemd be used. I pulled the file from this repo based off the above referenced documentation. The documentation is based off of building from source, so I can see that that is part of my issue.

Perhaps 3 things could occur:

1. Documentation addition (I am working on a bunch of proposed changes for the docs anyway) to include PPA install process
2. Additional version of the gsn3.service.systemd file to account for the different path when installed via PPA
3. Perhaps an option during PPA install of gns3-server that if selected would install the service?

[grossmj]

I think all those things would make sense, the first two would be the easiest to do. I can make the PPA install the service but should we make it an option?

For info, here is the service file we use in the GNS3 VM: https://github.com/GNS3/gns3-vm/blob/focal-stable/config/gns3.service

[eantowne]

I would say that it should definitely be an OPTION to install as a service. On a desktop install, it may not be desirable for some users to have it as a service. Additionally, having as a service may cause issues for anyone only using the VM or a remote server.

[blueneekone]

gns3.service.systemd default ExecPath location references /usr/bin/gns3server not /usr/local/bin/gns3server upon install via setup.py. I'm creating a pull request to make the change.

[grossmj]

gns3.service.systemd default ExecPath location references /usr/bin/gns3server not /usr/local/bin/gns3server upon install via setup.py.

It seems that when installing via setup.py, the gns3server executable is into /usr/bin/gns3server but it is in /usr/local/bin/gns3server if installing via pip... they surely don't make things easy.

One workaround would be to use python3 setup.py install --install-scripts=/usr/local/bin

However, it should be noted that setup.py install is deprecated: https://github.com/GNS3/gns3-server/issues/2013

[grossmj]

Some more information why this is happening: https://github.com/pypa/pip/issues/1728 not yet sure how to handle that...

[grossmj]

@eantowne

Perhaps an option during PPA install of gns3-server that if selected would install the service?

The next gns3-server Debian package will install a systemd service file but it won't be enabled / started by default, it will be up to users to do this if they wish to.

You may try with one of these packages if you would like to test: https://launchpad.net/~gns3/+archive/ubuntu/test/+packages

Here is the content of the systemd service file. Please let me know if there is anything to change.

[Unit]
Description=GNS3 server
After=network-online.target
Wants=network-online.target
Conflicts=shutdown.target

[Service]
PermissionsStartOnly=true
AmbientCapabilities=CAP_NET_BIND_SERVICE
EnvironmentFile=/etc/environment
ExecStart=/usr/bin/gns3server
ExecReload=/bin/kill -s HUP $MAINPID
Restart=on-failure
RestartSec=5
LimitNOFILE=16384

[Install]
WantedBy=multi-user.target

[eantowne]

@grossmj I finally had an opportunity to test this out on 2.2.35.1 last night. The file worked once I added the below to the [Service] section as otherwise I was not able to create a project as a local user on the same machine.

User= Group=

Needs to have some documentation somewhere for managing service user and group, plus how to handle local users on the same machine as server.

[grossmj]

I have added User and Group, let's test when v2.2.36 has been released

[eantowne]

I just did a clean install of 2.2.36 on WSL2. the service file found at: /usr/lib/systemd/system/gns3server.service does not have User= nor Group=, however the service seems to be starting fine and I am able to access the server and run appliances just fine. I need to test on my Pop-OS box for further validation.

[grossmj]

I just did a clean install of 2.2.36 on WSL2. the service file found at: /usr/lib/systemd/system/gns3server.service does not have User= nor Group=

Indeed, I added User=gns3 and Group=gns3 to gns3server.service on the 3.0 branch not 2.2... Seems they are not needed after all ;)

however the service seems to be starting fine and I am able to access the server and run appliances just fine. I need to test on my Pop-OS box for further validation.

Ok, let me know 👍 thanks

[eantowne]

Just tested on a couple other installs. Yes, it works without User= and Group=. The problem now is that it is running the server as root. Obviously, this is not good.

• My recommendation would be to specify the user/group based on $USER at time of install. This is not a perfect solution though.

• Ideally I think a curses dialog asking for user/group and whether to enable the service or not during the install would be best.

• Specifying user/group as gns3 during the install may not work due to that user may or may not exist, and permissions issues if the user decides to run the client locally and try to connect to the server from a different user.

[grossmj]

@eantowne

I think the best is I take example on another package. Do you know any Debian package that has an optional service?

[eantowne]

@grossmj Let me do some research and I will get back to you.

[eantowne]

@grossmj I am still looking for examples of how other projects handle this, I have not forgotten.

[grossmj]

@grossmj I am still looking for examples of how other projects handle this, I have not forgotten.

No worries, thanks :)

[grossmj]

Any update? ;) thanks.

[grossmj]

Implemented, will be supported in version 2.2.48